Pre-deploy Next.js checklist
Chaitanya Shetty published a production-ready Next.js/React pre-deploy checklist that covers build truth, runtime checks like hydration and environment variables, testing with Vitest and Playwright, and Cursor audits to catch issues before release. The checklist is pitched as a practical tool to make code reviews and release gates more credible and repeatable. (x.com)
Most Next.js bugs do not show up while you are building the page. They show up after `next build`, after real environment variables load, or after the browser tries to attach React to server-rendered HTML and finds that the two versions do not match. (nextjs.org, nextjs.org) That is the gap Chaitanya Shetty’s pre-deploy checklist is aimed at closing: not “did the app run on localhost,” but “did the production build, the production runtime, and the release review all agree on the same truth.” The checklist was published in a post on X by Shetty, who writes as The Chai Coder. (x.com) Next.js is a React framework that can render part of a page on the server before the browser loads it. That speed trick creates a second copy of the page in the browser, and if the browser copy differs from the server copy, React throws a hydration error instead of quietly papering it over. (nextjs.org, nextjs.org) A hydration error is the web equivalent of printing a boarding pass with seat 12A and then handing the gate agent a phone screen that says 14C. The app may still open, but buttons, state, or event handlers can attach to the wrong markup and produce bugs that are hard to reproduce. (nextjs.org) Environment variables are another place where local confidence breaks. Next.js loads values from `.env` files into `process.env`, but only variables prefixed with `NEXT_PUBLIC_` are bundled into browser code, which means a value can exist on the server and still be missing in the client. (nextjs.org) That is why a serious pre-deploy check asks whether the app was tested with production-like variables instead of developer defaults. A login flow that works with a local database URL and a fake public key can fail instantly when production secrets, domains, or callback URLs are different. (nextjs.org) The testing split in the checklist tracks the split in the framework. Next.js recommends Vitest for unit testing, but its own docs warn that Vitest does not currently support async Server Components, so it cannot be the only gate for a modern app. (nextjs.org) Vitest is the fast bench test: render a component, click a button, assert that one function returned the right thing. Playwright is the road test: open Chromium, Firefox, or WebKit, load the built app, and see whether routing, forms, cookies, and full-page flows survive a real browser session. (nextjs.org, nextjs.im) Cursor adds a different kind of check. Cursor’s review tools and Bugbot are designed to scan diffs and pull requests for bugs, security issues, and code quality problems, which turns an informal “looks fine to me” review into a repeatable pass over the exact files about to ship. (cursor.com, cursor.com) That combination is why this kind of checklist is spreading in teams shipping React apps with artificial intelligence tools in the loop. When code can be generated in minutes, the bottleneck moves from writing code to proving that the built artifact, the browser behavior, and the review process all line up before release. (cursor.com, nextjs.org) A good release gate is boring on purpose. If `next build` passes, hydration stays clean, production variables resolve, Vitest catches component regressions, Playwright catches browser regressions, and Cursor flags suspicious diffs before merge, the deploy stops being a leap of faith and starts looking like a checklist a team can trust. (nextjs.org, nextjs.org, cursor.com)
