TypeScript 6.0 shipped in March 2026 as the last JavaScript-based release before the Go-based TypeScript 7.0 compiler, and it changed seven tsconfig.json defaults at once — strict, module, target, types, rootDir, noUncheckedSideEffectImports, and libReplacement. Most teams noticed because their build either got 20-50% faster or filled with hundreds of new type errors overnight.
What nobody has written about yet: a lot of CLAUDE.md files carry a rule that tells Claude Code to turn on something that TypeScript 6.0 now turns on for you — or, worse, a rule written for the old defaults that now actively fights the new ones.
The rules that just went redundant
If your CLAUDE.md has a line like this, it did useful work under TypeScript 5.x and does nothing under 6.0:
- Use strict mode settings: `strict: true`, `noUncheckedIndexedAccess: true`.strict is true by default in TypeScript 6.0. The instruction isn’t wrong, it’s just inert — Claude Code will read it, nod, and find the setting already on. Not harmful on its own, but it’s a signal that the file hasn’t been re-read against the compiler it’s actually running.
The more expensive case is a rule that assumes the old default and is now silently wrong:
- Do not add `types` array restrictions in tsconfig — let TypeScript pull in all installed `@types` packages automatically.That instruction was reasonable advice against types: [] friction in 5.x, where types defaulted to ["*"]. In 6.0, types defaults to []. Following this rule now means Claude Code goes out of its way to widen the default back to ["*"], undoing the build-time win TypeScript just gave you for free — 20-50% faster type checking, per the official release notes, from not vacuuming up every @types package in node_modules.
What actually changed, and what it means for the rule
| tsconfig field | Old default | TS 6.0 default | What to check in your CLAUDE.md |
|---|---|---|---|
strict | false | true | Remove instructions to manually enable it; keep instructions for options strict doesn’t cover (exactOptionalPropertyTypes, noUncheckedIndexedAccess are separate flags, still off by default) |
module | commonjs | esnext | Any rule assuming CommonJS import/require patterns needs a rewrite — require() guidance is now the exception case, not the default |
target | es2015 | es2025 (floating, tracks current year) | Rules pinning a specific target for browser compat should say so explicitly now, since the default moves every year |
types | ["*"] | [] | Don’t tell Claude Code to “just let it pull in all @types” — it has to be told which packages to list explicitly now |
rootDir | inferred from include | . (tsconfig’s own directory) | If your repo has a src/ layout, this needs an explicit rule or Claude Code’s file resolution will assume the wrong root |
esModuleInterop / allowSyntheticDefaultImports | opt-in | must be true | import * as express from "express" guidance is now wrong; import express from "express" is the only supported form |
Two other removals worth a CLAUDE.md line if your codebase still touches them:
target: es5is gone. If a rule exists for IE-era output, it needs to be deleted, not updated — there’s no migration path, only “use es2015 or higher.”module amd|umd|systemjs|noneare gone. If Claude Code has ever suggested one of these for a legacy bundler setup, that suggestion is now a compile error, not a warning.
The CLAUDE.md block worth adding
Instead of re-declaring what the compiler already defaults to, point the rule at the parts of the transition that are still manual:
## TypeScript 6.0 Baseline
- This project targets TypeScript 6.0+. Do not add `strict: true`, `esModuleInterop: true`,
or `module: "esnext"` to tsconfig.json — these are 6.0 defaults, not project-specific choices.
- `types` defaults to `[]` in 6.0. If a new file needs ambient types (`node`, `jest`, etc.),
add the package to `compilerOptions.types` explicitly rather than assuming it's picked up.
- `rootDir` now defaults to the tsconfig directory, not the inferred common root of `include`.
If Claude Code sees unexpected output paths, check this first before touching `include`/`exclude`.
- Do not use `module Foo { ... }` namespace syntax — deprecated in 6.0, removed in 7.0. Use `namespace Foo { ... }`.
- Do not use `import x from "./data.json" asserts { type: "json" }` — deprecated in 6.0. Use `with { type: "json" }`.
- If a deprecation warning references `ignoreDeprecations: "6.0"`, do not add that flag to silence it.
TypeScript 7.0 removes the deprecated options entirely; suppressing the warning just delays the migration.That last line matters more than it looks. ignoreDeprecations is a snooze button, and the codebase that reaches for it under time pressure is the one that gets a wall of errors on the day 7.0 lands. Telling Claude Code not to reach for it by default is cheaper than explaining the same thing in a PR review six months from now.
Where this doesn’t apply
None of this replaces a general TypeScript CLAUDE.md setup — type-safety patterns like preferring satisfies over as, banning non-null assertions on external data, and exhaustive union narrowing are still project-level decisions TypeScript 6.0 doesn’t make for you. For that baseline template, see our TypeScript CLAUDE.md rules guide. This piece is specifically about the rules that TypeScript 6.0’s new defaults made redundant or wrong, which is a narrower and more perishable problem — worth a version bump note in CLAUDE.md, not a full rewrite.
If you’re building out rules for other stacks that shifted defaults recently, our gallery has CLAUDE.md and AGENTS.md examples across frameworks and runtimes, including the Bun 1.4 and React Router v7 transitions from this same release cycle.