Build1 publisher3 min readPublished
TypeScript 7 deletes the tsconfig options that ignoreDeprecations was hiding
TypeScript 7.0, the Go-native compiler GA since July, removes the options 6.0 deprecated, so ignoreDeprecations only postponed the break. The audit has to run on 6.0, while tsc still names each option it will drop.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- The rootDir default is now the tsconfig's own directory, and emitted output can silently move from dist/index.js to dist/src/index.js.
- Strict mode is on by default, module defaults to esnext, and target floats to the newest supported spec, currently es2025.
- An experimental ts5to6 codemod from the TypeScript team rewrites baseUrl and rootDir settings across a monorepo.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision The audit has to run on 6.0 with warnings visible; once 7.0 removes the options, the deprecation warning that named each one goes with them.
- exposure Libraries that publish with tsc carry the rootDir risk: a release can pass its build and still ship a package.json main that points at nothing.
- cost Codebases that relied on strict defaulting to false face every strictNullChecks and noImplicitAny error at once unless they pin strict: false and clear the checks one by one.
- capability Listing types explicitly can cut build times, though the reported 20 to 50 percent depends on a monorepo hauling in hundreds of unused @types packages.
On 6.0, setting `"ignoreDeprecations": "6.0"` silences the warnings and the build carries on [3]. On 7.0 the deprecated options are removed outright [2]. A dev.to walkthrough of the migration states the result plainly: "you didn't fix anything. You scheduled the breakage for your TS 7 upgrade." [3]
The flag addresses the deprecated options [3]. The other half of 6.0 was a batch of changed defaults, and 7.0 keeps them as its baseline [1][2]. According to the post, the TypeScript team flagged two of them up front because their errors do not point at the cause [16]. With `types` defaulting to an empty list, a project that never named its @types packages gets `Cannot find name 'process'` errors that look like a broken install [4]. The `rootDir` change produces no error at all. Output moves from `dist/index.js` to `dist/src/index.js`, and the package.json `main` field points at a file that is no longer there [6]. Bundler setups with `noEmit` are unaffected. Libraries published with tsc are the ones to check first [7].
`baseUrl` is the deprecated option most frontend projects hit, per the post [10]. It did two jobs [10]. It was a prefix for `paths`, and it was a lookup root that let TypeScript resolve `import x from "utils"` to `src/utils.ts`, an import no bundler would resolve [10]. The prefix job has a mechanical fix: delete `baseUrl` and write the mapping out in full as `"@/*": ["./src/*"]` [11]. For older projects that still emit CommonJS but used node10 resolution, 6.0 now allows `moduleResolution: "bundler"` alongside `module: "commonjs"` [12].
The post relays a TypeScript team report that many projects built 20 to 50 percent faster after listing only the types they use [5]. The stated cause is that a typical monorepo transitively pulls in hundreds of @types packages nobody imports [5]. For that range to hold elsewhere, a project has to carry a similar load of unused @types. A small single-package app has less to drop and should expect less [1]. Setting `"types": ["*"]` restores the old load-everything behaviour, and the post advises against it [20].
Strict mode now defaults to true. A codebase that leaned on the old false default gets every `strictNullChecks` and `noImplicitAny` error at once [8]. The post's advice is to set `strict` explicitly either way, writing `"strict": false` if the code is not ready and enabling individual checks one at a time [17]. I think the post has this right for any team that inherited the old default, because the decision then sits visibly in the file [17]. `noUncheckedSideEffectImports` is also on, so a typo such as `import './polyfil'` now fails where it used to do nothing [9].
The sequence the post lays out runs entirely on 6.0, before the 7.0 binary goes in [13][15]:
1. Remove `ignoreDeprecations` from every tsconfig [13]. 2. Run `tsc --noEmit` and file each warning as a ticket [13]. 3. Use the TypeScript team's experimental ts5to6 codemod to rewrite `baseUrl` and `rootDir` across a monorepo [14]. Experimental is the team's own label, so read the diff before merging it. 4. Turn on `--stableTypeOrdering`, which makes the JS compiler order types the way the Go compiler does, and clear any inference differences it exposes [15]. 5. Switch binaries [15].
Once 6.0 is clean, the post expects 7.0 to be uneventful on the config side [18].
What to watch
- Whether the ts5to6 codemod leaves experimental status, and which baseUrl or rootDir layouts it fails to rewrite in large monorepos.
- Build-time measurements from teams outside the TypeScript project after switching to an explicit types list, to test the 20 to 50 percent range.
- Inference differences that --stableTypeOrdering surfaces on 6.0 codebases ahead of the swap to the Go compiler.