TypeScript 6.0 RC: No CVEs, but your build integrity just changed

No CVEs disclosed. Patch your CI before your next standup, or expect nondeterministic .d.ts artifacts and failing compiler jobs.

Security impact (compliance view)

I have watched teams lose a full day because two “identical” CI runs produced different declaration files. Nothing crashed at runtime, but the release artifact hash changed, the diff review exploded, and the audit trail turned into a shrug. That is a build integrity failure, not a developer inconvenience.

If you do not upgrade and test now, you risk shipping packages where the declared API surface changes between runners. An attacker does not need remote code execution for that to hurt you. They only need you to stop trusting your own artifacts.

Attack surface change: TypeScript 6.0 RC tightens CLI behavior and type output ordering in ways that directly affect what you publish in .d.ts files.
Compliance risk: Nondeterministic declaration emit breaks reproducible builds. That breaks artifact attestation. It also breaks “we can explain what changed” during incident response.
Until we see a PoC, the real risk is: pipeline drift. You approve one declared surface in code review, then you publish a slightly different one from another runner.

No security fixes does not mean no security impact. Build determinism is a control.

Breaking changes you will feel in CI

This fails fast. Good.

TypeScript 6.0 RC turns a few “ambiguous but works” behaviors into hard errors. That breaks scripts that relied on sloppy defaults. It also removes an old lib directive some repos still carry like a fossil.

TS5112: file arguments plus tsconfig now error

The thing nobody mentions is how often repos still run tsc foo.ts in random scripts. I keep finding it in Makefiles and pre-commit hooks, usually written by someone who left two years ago.

TypeScript 6.0 RC throws TS5112 when you specify input files and a tsconfig.json exists, unless you opt into the old behavior with –ignoreConfig. If you do not fix this, your “quick compile” job starts failing, and people will bypass CI to get work done. That is the threat scenario.

Fix (use the repo config): run npx tsc -p tsconfig.json in CI and in scripts.
Fix (intentionally ignore repo config): run npx tsc –ignoreConfig path/to/foo.ts, but do not allow this in compliance-managed CI without a documented exception.
Detection: grep for tsc *.ts, tsc src/, and tsc foo.ts patterns across scripts and hooks.

Removed: /// <reference no-default-lib=”true”/>

This bit me once in a multi-tsconfig monorepo. One legacy package “worked” only because it suppressed default libs, then a dependency bump brought DOM types back and the whole project started compiling against globals it never meant to allow.

TypeScript 6.0 RC removes the triple-slash no-default-lib directive. Migrate to –noLib or –libReplacement. If you do nothing, you can accidentally reintroduce ambient types, change what “exists” globally, and ship types that do not match your runtime constraints.

Fix: replace the directive with –noLib or –libReplacement, then document the intended global environment in the tsconfig.
Failure mode: “Why did DOM types come back?” or “Why did my globals disappear?” shows up after a seemingly unrelated upgrade.

Build output determinism: –stableTypeOrdering (use it like a probe)

Non-reproducible output is a release control failure.

TypeScript’s type ordering can leak into declaration emit and snapshot-driven tooling. TypeScript 7 moves to deterministic, content-based ordering to support parallel work, and TypeScript 6.0 RC exposes a compatibility switch: –stableTypeOrdering. The advisory does not promise zero behavior changes. It only gives you a way to separate ordering noise from real semantic deltas.

The catch is cost. The TypeScript 6.0 RC announcement calls out up to 25% slower type-checking depending on the codebase. I treat that as a temporary forensic tool. Some folks will leave it on forever. I do not, unless the repo ships public types and I cannot otherwise explain the diffs.

Use case: isolate “ordering-only” .d.ts churn during TS6 to TS7 migration.
Command: npx tsc -p tsconfig.json –stableTypeOrdering
If you do not do this: reviewers will approve noisy diffs, and one real API surface change will hide inside the churn.

Everything else that still matters (inference and JSX)

These failures feel random. They are not.

TypeScript 6.0 RC backports inference and JSX fixes from the TypeScript 7 codebase (PR #63163). That can change which expressions infer cleanly, especially around generic JSX call sites and conditional returns with different function shapes. You may see new implicit-any failures like TS7006. Until we see a PoC, the real risk is not “types got stricter.” The risk is engineers papering over new errors with any to get a build green again.

What to watch: new type-check errors after refactors that should not affect runtime.
Where it hits: JSX children typing, unions, and inference that previously relied on quirks.
If you do not upgrade in a controlled way: you will accept a broad “fix” PR that adds unsafe casts across the codebase.

Upgrade procedure (paranoid version)

Do this in a branch. Not on Friday.

Pin the RC, run the compiler in a clean workspace, and fail on the first sign of nondeterminism. If your CI caches node_modules aggressively, clear it once for this test. Caches hide problems, then they dump them on you during a hotfix.

Install the RC: npm install -D typescript@rc
Run with explicit project config: npx tsc -p tsconfig.json –pretty false
Probe ordering diffs: npx tsc -p tsconfig.json –stableTypeOrdering

Red flags to gate in CI

Fail the build. Every time.

Put these in your CI log filters and treat them like policy violations. If you ignore them, you will normalize drift, and drift always becomes an incident later.

TS5112: decide between -p and –ignoreConfig, then delete the ambiguous call.
Declaration snapshot churn: large order-only diffs in unions or type displays. Re-run with –stableTypeOrdering to confirm it is noise.
New implicit-any around JSX/inference: investigate the inference site. Do not “fix” it with a repo-wide any sweep.
Lib environment regression: projects that relied on no-default-lib now compile with a different global surface. Confirm DOM and Node globals match your intended runtime.