Next.js 16.3 and TypeScript 7 Upgrade Guide

Next.js 16.3 and TypeScript 7 are complementary upgrades: the framework now supports the native TypeScript compiler during next build, while TypeScript 7 replaces the JavaScript compiler with a multithreaded native port written in Go.

The dependency changes are small. The compatibility review should still be deliberate. TypeScript 7 removes old compiler options and does not yet expose a stable JavaScript compiler API, while Next.js 16.3 includes new opt-in runtime behavior that should not be enabled as an accidental side effect of a package upgrade.

Both Achromatic starter kits now ship Next.js 16.3.0 and TypeScript 7.0.2. This guide explains what changed, which claims come from the upstream projects and what we checked before preparing the release.

What Next.js 16.3 changes

The official Next.js 16.3 announcement groups the release around navigation, development performance, builds and tooling.

The headline addition is Instant Navigations, an opt-in set of caching and navigation features intended to make App Router transitions feel closer to a single-page application. Next.js 16.3 also adds persistent Turbopack build caching, lower development-server memory use, TypeScript 7 support in next build and server-rendering improvements.

The performance figures in the announcement are Vercel's upstream benchmarks, not Achromatic measurements. Vercel reports up to 90% lower development-server memory use, cached build improvements that vary by codebase and up to 22% higher server-rendering throughput in its tests. Treat those figures as useful release context, not a promise for every application.

For an existing SaaS product, the safest first step is simply to update the framework. Do not enable a new caching or navigation model in the same commit unless you intend to review its data-freshness and loading behavior separately.

Why TypeScript 7 is different

TypeScript 7 is a native port of the compiler and language service. Microsoft reports typical full-build speedups between 8x and 12x across the large open-source projects in its release tests, alongside lower aggregate memory use in those examples. Again, these are upstream results; measure your own project and CI environment before turning them into planning assumptions.

The migration is more than a faster tsc. TypeScript 7 adopts the TypeScript 6 defaults and converts several TypeScript 6 deprecations into hard errors. Projects still using options such as target: es5, baseUrl, classic or Node 10 module resolution, or legacy module formats must update their configuration.

Modern Next.js App Router projects are usually well positioned. Achromatic already used an ES2022 target, moduleResolution: "Bundler", strict checking and project-relative path mappings, so both kits compiled without a tsconfig compatibility change.

The compiler API needs special treatment

TypeScript 7.0 does not ship a stable JavaScript compiler API. That matters to tools that import typescript and inspect an abstract syntax tree, even when the application itself type-checks cleanly.

Pro Drizzle's local MCP server is one example. Its database adapter reads the checked-in TypeScript schema to describe tables, fields, indexes and constraints. That parser needs the TypeScript compiler API; the application compiler does not.

Microsoft explicitly supports this transition with @typescript/typescript6. Achromatic keeps typescript@7.0.2 as the project compiler and imports the official TypeScript 6 compatibility API only inside the Drizzle MCP parser. This preserves the read-only schema inspection behavior without running the application typecheck on the old compiler.

Search your own repository before upgrading:

rg 'typescript' --glob '*.ts' --glob '*.tsx'

If the result includes a custom code generator, AST transform or build tool, read Microsoft's side-by-side guidance before changing its import. Do not add the compatibility package when no tool uses the compiler API.

A focused upgrade sequence

Update Next.js and its matching analyzer together, then install the new compiler:

npm install --save-exact next@16.3.0 @next/bundle-analyzer@16.3.0
npm install --save-dev --save-exact typescript@7.0.2

Verify the versions recorded by the lockfile:

npm ls next @next/bundle-analyzer typescript

Then run validation in layers:

npm run typecheck
npm run lint
npm run format
npm run test:unit
npm run build

Compile custom tooling independently when the repository has a separate tsconfig. Achromatic runs npm run mcp:build in addition to the application typecheck so a green app build cannot hide an MCP compiler-API failure.

Finally, exercise the workflows that framework upgrades cannot prove through static analysis: authentication, organization selection, account settings, administrative authorization, billing callbacks and any custom Server Actions.

What changed in Achromatic

The Pro Prisma and Pro Drizzle releases contain the same framework and project compiler versions:

Pro Drizzle additionally records the official TypeScript 6 compatibility package for its MCP parser and explicit PostgreSQL declarations used by the test database helper. Pro Prisma does not parse TypeScript source through the compiler API, so it does not need that package. Its Prisma client, PostgreSQL adapter and CLI were also moved to 7.9.1 after that patch resolved newly reported dependency advisories; the patch does not change the database schema.

Both editions passed clean lockfile installation, application type checking on TypeScript 7, MCP compilation, Oxlint, Oxfmt, their unit suites and production builds. The update does not change the database schema and requires no migration.

Keep feature adoption separate

A dependency upgrade is easier to review when it preserves application behavior. Instant Navigations, Cache Components and experimental compiler options deserve their own design decision, test plan and rollout.

That separation gives you a useful rollback boundary: first adopt the supported framework and compiler versions; then evaluate opt-in behavior with real route, cache and product requirements. It also keeps upstream performance claims from being confused with results you have actually measured in your application.

The refreshed Pro Prisma documentation and Pro Drizzle documentation describe the current kits, while the release entry records the exact coordinated update.