Plate 17
TypeScript 7: Should You Upgrade? 10.2s to 1.4s on Hono
TypeScript 7 upgrade decision with ShopperCove timing on Hono (906 files): median 10.23 s on 6.0.3 vs 1.41 s on 7.0.2 (7.3x), peak RSS 1,032 MB vs 718 MB, plus 2 moved @ts-expect-error targets and the typescript-eslint <6.1 peer limit.
Aditya Challa6 min read
Yes, move your command-line type-check to TypeScript 7 if your project already passes TypeScript 6.0 with no deprecation errors. On 5 Oct 2026 I type-checked Hono's 906-file test project with TypeScript 6.0.3 and 7.0.2: the median dropped from 10.23 s to 1.41 s (7.3x), peak memory fell from 1,032 MB to 718 MB, and 7.0.2 reported 2 errors that 6.0.3 never showed.
Wait on the editor side if you use Vue, Svelte, Astro, MDX or type-aware typescript-eslint rules. TypeScript 7.0 ships without a programmatic API, so those tools still need 6.0 installed next to it. No affiliate links in this post.
What I tested
- Machine: 8 vCPU / 15 GB RAM Linux cloud box (kernel 6.12). Node 24.21.0 runs TypeScript 6; TypeScript 7 is a native Go binary.
- Compilers:
typescript@6.0.3andtypescript@7.0.2, installed side by side with npm aliases. - Codebase: Hono
mainat commit5f36607(5 Oct 2026, 14:59 IST), package version 4.13.13, dependencies from its lockfile via pnpm 12.6.0. - Command:
tsc -p <config> --noEmit, three runs per cell, median reported. Peak memory is max RSS fromgetrusage. - One surprise: Hono's base config sets
composite: true, so a leftover.tsbuildinfoturns the next run into an incremental check. My first pass showed TypeScript 7 at 0.23 s for that reason. I deleted the build info before every timed run below. - Not tested: editor and LSP latency,
--buildwith project references, emit, watch mode, Windows or macOS.
How much faster is TypeScript 7 on a real project?
| Hono config | Files | TS 6.0.3 median | TS 7.0.2 median | Speedup | Peak RSS (6 → 7) |
|---|---|---|---|---|---|
tsconfig.build.json (src only) | 363 | 3.02 s (3.02 / 2.95 / 3.09) | 0.65 s (0.70 / 0.65 / 0.63) | 4.6x | 524 MB → 337 MB |
tsconfig.spec.json (src + tests) | 906 | 10.23 s (9.59 / 10.37 / 10.23) | 1.41 s (1.41 / 1.45 / 1.41) | 7.3x | 1,032 MB → 718 MB |
Microsoft's TypeScript 7.0 announcement reports 8x to 12x on much bigger codebases such as VS Code (125.7 s → 10.6 s). My numbers sit below that range, which is what I expected: on a 363-file project, process start and setup are a bigger share of the total. The larger Hono config got closer to the official range.
With the build info left in place, a no-change second run took 0.23 s on 7.0.2 and 1.50 s on 6.0.3 (one run each).
Does --checkers help on an 8-core machine?
TypeScript 7 runs 4 type-checker workers by default. I timed the 906-file config with the new flags:
| TS 7.0.2 flag | Median | Peak RSS |
|---|---|---|
| default (4 checkers) | 1.41 s | 718 MB |
--checkers 8 | 1.46 s (1.41 / 1.53 / 1.46) | 872 MB |
--checkers 1 | 2.74 s (2.74 / 2.86 / 2.52) | 552 MB |
--singleThreaded | 2.94 s (2.94 / 3.00 / 2.83) | 552 MB |
Doubling checkers bought nothing at this size and cost about 150 MB more. Even fully single-threaded, 7.0.2 beat 6.0.3 by about 3.5x. On small CI runners I would pin --checkers 2 or --checkers 1. Pinning a fixed number also keeps results identical across machines, which the TypeScript team recommends because checker count can surface order-dependent results in rare cases.
Will TypeScript 7 break my build?
I hit two kinds of breakage.
Config errors. I wrote a small legacy tsconfig.json with target: es5, moduleResolution: node, baseUrl plus a non-relative paths entry, and downlevelIteration. TypeScript 6.0.3 already flags these as deprecated (TS5107 / TS5101) unless you set ignoreDeprecations: "6.0". TypeScript 7.0.2 removes the escape hatch: it prints TS5108 / TS5102 "has been removed" for each option, plus TS5090 "Non-relative paths are not allowed" for the paths entry that leaned on baseUrl. Fix these on 6.0 first.
Diagnostic placement. Hono's test suite has two // @ts-expect-error comments above app.on( calls with ten middleware arguments. With the directives removed, 6.0.3 reports TS2769 "No overload matches this call" at line 3417 (the app.on( line). 7.0.2 reports the same error two lines lower, on the '/on/10' argument. Because a directive only covers the next line, 7.0.2 shows TS2578 "Unused '@ts-expect-error' directive" plus the uncovered TS2769, which makes 4 diagnostics for 2 real differences. If you use @ts-expect-error on multi-line calls, expect a few of these.
Tooling. typescript-eslint 8.71.0 declares typescript: ">=4.8.4 <6.1.0" as its peer range, so type-aware lint stays on 6.0 for now. I covered its newest rule in the typescript-eslint 8.71 post. Vue projects should keep 6.0 for vue-tsc too; see the vue-tsc 3.3.12 notes.
How do I upgrade without breaking lint?
- Get clean on TypeScript 6.0 with no
ignoreDeprecationssetting. AddrootDirand an explicittypeslist if you relied on the old defaults (7.0 defaultstypesto[]). - Use the alias setup from the announcement so
tscis 7.0 and every tool importingtypescriptstill gets 6.0:
- Run
tsc --noEmit(7.0) andtsc6 --noEmit(6.0) in CI for a week and diff the output. Look for moved@ts-expect-errortargets first. - Pin
--checkersin CI. - In VS Code, install the TypeScript 7 extension. For Vue, Svelte, Astro or MDX workspaces, run "Disable TypeScript 7 Language Server" until 7.1 ships its API. The same holds if you are on the Astro 7.3 preview or a SvelteKit 3 migration.
Should you upgrade to TypeScript 7?
| Your setup | My call |
|---|---|
Plain TS or React app, bundler or nodenext resolution, clean on 6.0 | Upgrade CLI and editor now |
| Type-aware typescript-eslint | Upgrade tsc through the alias; keep 6.0 for lint |
| Angular | TS 7 for CLI checks, 6.0 for template type-checking in the editor |
| Vue, Svelte, Astro, MDX | CLI checks only where possible; editor stays on 6.0 until 7.1 |
target: es5, baseUrl, node10 resolution | Fix the config on 6.0 first |
Custom transformers or loaders that import the typescript API | Wait for 7.1 |
Bottom line: on Hono the type-check went from about 10 seconds to about 1.4 seconds with 30% less memory, and the only code changes needed were two moved @ts-expect-error comments. Who should not bother yet: teams whose day-to-day pain is in Vue or Svelte editor tooling, because 7.0 does not reach there.
How this was made: I ran every command above on the ShopperCove test box and kept the raw output; the write-up was drafted with AI help and checked against that output.
Sources
- https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
- https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-rc/
- https://github.com/microsoft/typescript-go/blob/main/CHANGES.md
- https://www.npmjs.com/package/typescript
- https://www.npmjs.com/package/@typescript/typescript6
- https://typescript-eslint.io/users/dependency-versions
- https://github.com/honojs/hono
- https://www.infoq.com/news/2026/08/typescript-7-released/
Related
- https://www.shoppercove.com/blog/typescript-eslint-8-71-no-unsafe-enum-assignment-october-2026
- https://www.shoppercove.com/blog/vue-language-tools-3-3-12-definemodel-css-modules-october-2026
- https://www.shoppercove.com/blog/astro-7-3-preview-ignore-lock-october-2026
- https://www.shoppercove.com/blog/sveltekit-3-migration-checklist-october-2026
- https://www.shoppercove.com/blog/biome-2-5-15-type-inference-nursery-rules-october-2026
- https://www.shoppercove.com/blog/oxlint-1-87-react-suggestions-a11y-fixes-october-2026
- https://www.shoppercove.com/blog/vite-8-3-2-renderbuilturl-bundled-dev-sourcemaps-october-2026
- https://www.shoppercove.com/blog/nodejs-26-lts-october-2026-schedule-change
Lab evidence
What I found running this
Sources read 5 Oct 2026 evening (Asia/Calcutta): devblogs.microsoft.com/typescript/announcing-typescript-7-0/ (8 Jul 2026; 8-12x claim; no API until 7.1; @typescript/typescript6 alias; defaults strict/esnext/types=[]; removed es5/baseUrl/node10). npm typescript latest=7.0.2 (published 2026-07-08T15:55Z, ~21:25 IST); typescript-eslint 8.71.0 peer typescript '>=4.8.4 <6.1.0'; @typescript/typescript6 latest 6.0.2. Hands-on on box (8 vCPU/15 GB, Node 24.21.0): Hono main 5f36607 (2026-10-05T18:29:52+09:00 = 14:59 IST), pnpm 12.6.0 frozen lockfile; tsc -p <cfg> --noEmit, tsbuildinfo deleted each run, 3 runs. tsconfig.build.json 363 files: TS6 3.02/2.95/3.09 s (RSS ~524 MB) vs TS7 0.70/0.65/0.63 s (~337 MB). tsconfig.spec.json 906 files: TS6 9.59/10.37/10.23 s (~1,032 MB) vs TS7 1.41/1.45/1.41 s (~718 MB). TS7 spec flags: --checkers 8 1.41/1.53/1.46 s (~872 MB); --checkers 1 2.74/2.86/2.52 s (~552 MB); --singleThreaded 2.94/3.00/2.83 s (~552 MB). Incremental no-change rerun: TS7 0.23 s vs TS6 1.50 s. TS7 spec: 4 diagnostics (2x TS2578 + 2x TS2769, src/hono.test.ts 3416/3419, 3547/3550); with directives removed TS6 reports TS2769 at 3417:7/3548:7, TS7 at 3419:5/3550:5. Legacy tsconfig fixture: TS6 TS5107/TS5101 deprecations; TS7 TS5108/TS5102 removed + TS5090 non-relative paths. No ShopperCove production code changed. No affiliate.
Related links
Plate 12
Yarn Berry vs pnpm: 1.3s vs 0.24s Install
Yarn 4.9.2 (Berry PnP + node-modules linker) vs pnpm 12.9.1 on one 22-dependency React+Vite app. Isolated caches (Yarn enableGlobalCache false; pnpm --store-dir). Warm medians (5): Yarn PnP 1.307 s, Yarn nm 2.471 s, pnpm 0.240 s. Lock+empty medians 1.656 / 2.789 / 0.725 s. Clean disk: Yarn PnP 246 MB; Yarn nm modules 189 MB; pnpm hardlink project 167 MB. Fixture /workspace/bench-yarn-pnpm/. Distinct from pnpm-vs-npm-vs-bun (no Yarn).
5 Oct 2026
Plate 48
Zod vs Valibot: 1.14M vs 0.97M Parses
zod 4.6.5 vs valibot 1.5.0 on one nested user schema (uuid/email/age/tags/profile/enum). Warm medians after 2k warmup + 9×50k: zod.parse 1,144,494 ops/s vs valibot.parse 968,187 (~1.18×). safeParse fail: valibot 697,760 vs zod 415,523 (~1.7×). esbuild minify+gzip9: 452,999/92,636 B vs 85,126/15,422 B. Package trees ~6.1 MB vs ~1.9 MB. Fixture /workspace/bench-zod-valibot/.
5 Oct 2026
Plate 55
mozjpeg vs libvips: 385ms vs 31ms Encode
mozjpeg cjpeg 3.3.1 (mozjpeg npm 8.0.0) vs libvips jpeg via sharp 0.35.5 (mozjpeg:false) on one 1920×1080 JPEG → q80. Warm medians (7 rounds after 1 warm-up): cjpeg 385 ms / 675,128 B vs libvips jpeg 31 ms / 675,714 B (~12×). Context: sharp mozjpeg:true 308 ms / 546,546 B. Fixture /workspace/bench-mozjpeg-libvips/. cjpeg timed with spawn + PPM read.
5 Oct 2026