After a TypeScript 6 upgrade, dist/index.js may move to dist/src/index.js even though no source path changed. The compiler now uses a different rootDir default, and the new output layout is the visible result.

The useful question is not whether the release sounds modern. It is whether the changed default or capability affects the way your project installs, compiles, resolves modules, or runs in production.

Quick answer

Set rootDir explicitly to the directory that should become the root of emitted files, usually ./src, then inspect whether tests, scripts, or config files outside that directory are being compiled.

{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist"
  },
  "include": ["src"]
}

what changed

TypeScript 6 changes the default rootDir to the directory containing tsconfig.json. Projects that relied on inference from their included source files can therefore gain an extra src segment in output paths.

This is a version-specific change. Pin the tool or runtime while migrating so a teammate and CI do not test a different contract by accident.

where teams will notice it

Start scripts, Docker images, package main fields, and serverless entry points may still look for the old emitted path. The code compiled successfully, but deployment fails because the artifact contract changed.

A small smoke test is more useful than assuming the changelog covers your architecture. Reproduce the workflow from a clean checkout with the same command production uses.

a safe migration

  1. Inspect tsc --showConfig before and after upgrading.
  2. Set rootDir and outDir explicitly.
  3. Limit include to emitted source.
  4. Update no paths until the rebuilt artifact tree is confirmed.

Change one resolution or security boundary at a time. That keeps failures attributable and makes rollback straightforward.

the mistake to avoid

Do not fix this only by changing node dist/src/index.js. That accepts an accidental output contract and may hide unrelated files being emitted.

Avoid broad compatibility switches unless they are temporary, documented, and assigned a removal date. A migration that merely hides the warning will return as a harder TypeScript, Node, or npm upgrade later.

how to verify the result

Remove dist, run the build, and list the emitted entry point. Then run the same command used by production rather than relying only on type-check success.

Record the tool version and verification command in the pull request. That gives reviewers evidence and gives the next upgrade a known baseline.

rollout note

Ship the change in a small pull request that records the old behavior, the new behavior, and the rollback command. For an application, test the production image rather than only the developer machine. For a library, install the packed tarball in a tiny consumer project. Keep the previous lockfile or compiler configuration available until CI, deployment, and one real workflow have all passed.

That evidence makes the upgrade reviewable. It also prevents a later failure from being blamed vaguely on the entire major release when one setting or experimental flag was responsible.

official reference

Check the linked documentation again before upgrading production. Current-release features and announced security timelines can change in later patch releases.