Search Terms
noEmit --build --dry, tsconfig.tsbuildinfo noEmit dry build, noEmit index.js does not exist dry build, build dry noEmit project references out-of-date
Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about
--build, noEmit, and project references.
- Reproduced with
typescript@5.9.3.
- Reproduced with
typescript@next version 7.1.0-dev.20260717.1.
- Also reproduced with the TypeScript-Go port,
tsgo version 7.0.0-dev+effect-tsgo.0.14.5.
Playground Link
No Playground link. This requires a multi-tsconfig.json project-reference graph and tsc --build --dry.
Code
tsconfig.json
{
"files": [],
"references": [
{
"path": "./lib"
}
]
}
lib/tsconfig.json
{
"compilerOptions": {
"noEmit": true
},
"files": ["index.ts"]
}
lib/index.ts
Run:
tsc --version
tsc --build tsconfig.json --dry --noCheck --verbose
tsc --build tsconfig.json --verbose
tsc --build tsconfig.json --dry --noCheck --verbose
tsc --build tsconfig.json --verbose
tsc --build tsconfig.json --dry --noCheck --verbose
tsc --build tsconfig.json --dry --verbose
Actual behavior
The first dry run reports the referenced noEmit project as out of date because build info does not exist:
Version 5.9.3
Projects in this build:
* lib/tsconfig.json
* tsconfig.json
Project 'lib/tsconfig.json' is out of date because output file 'lib/tsconfig.tsbuildinfo' does not exist
A non-dry build would build project '/tmp/ts-noemit-dry-repro/lib/tsconfig.json'
A non-dry build creates lib/tsconfig.tsbuildinfo but, correctly, does not create lib/index.js because noEmit is enabled:
Project 'lib/tsconfig.json' is out of date because output file 'lib/tsconfig.tsbuildinfo' does not exist
Building project '/tmp/ts-noemit-dry-repro/lib/tsconfig.json'...
After that, repeated dry and non-dry builds keep reporting the project as stale because lib/index.js does not exist:
Project 'lib/tsconfig.json' is out of date because output file 'lib/index.js' does not exist
A non-dry build would build project '/tmp/ts-noemit-dry-repro/lib/tsconfig.json'
This remains true after a second non-dry build:
Project 'lib/tsconfig.json' is out of date because output file 'lib/index.js' does not exist
Building project '/tmp/ts-noemit-dry-repro/lib/tsconfig.json'...
Project 'lib/tsconfig.json' is out of date because output file 'lib/index.js' does not exist
A non-dry build would build project '/tmp/ts-noemit-dry-repro/lib/tsconfig.json'
It is not specific to --noCheck; tsc --build tsconfig.json --dry --verbose reports the same missing lib/index.js output after the project has been built.
Expected behavior
Question: is this intended for noEmit projects in a --build references graph?
If this project shape is supported, I would expect build up-to-date logic not to require emitted JavaScript outputs for a project whose compilerOptions.noEmit guarantees those outputs will never exist. After a non-dry build creates the relevant build info, --build --dry should not report the project as perpetually needing a build because lib/index.js is missing.
If this project shape is not supported, it would be useful for --build to report that directly rather than producing a perpetual stale-output result.
Additional information about the issue
The same repro also appears in the TypeScript-Go port:
Version 7.0.0-dev+effect-tsgo.0.14.5
Project 'lib/tsconfig.json' is out of date because output file 'lib/tsconfig.tsbuildinfo' does not exist
A non-dry build would build project '/tmp/tsgo-noemit-dry-repro/lib/tsconfig.json'
Building project 'lib/tsconfig.json'...
Project 'lib/tsconfig.json' is out of date because output file 'lib/index.js' does not exist
A non-dry build would build project '/tmp/tsgo-noemit-dry-repro/lib/tsconfig.json'
Posted on behalf of @schickling
| field |
value |
agent_name |
💎 co1-zenith |
agent_session_id |
0dee9117-f0f2-441f-a561-bbb08f2c7e5d |
agent_tool |
Codex CLI |
agent_tool_version |
0.144.1 |
agent_runtime |
Codex CLI 0.144.1 |
agent_model |
unknown |
runtime_profile |
/nix/store/1n76sy6i9y3ki3k4w04jksqvygw67sj0-coding-agent-runtime-profile/share/coding-agents/profile.json |
skills_manifest |
/nix/store/jn6r0r7r59x3a525jch4pwzwykszqp60-agent-skills-corpus/share/agent-skills/manifest.json |
worktree |
effect-utils/schickling/2026-07-17-tsgo-refactor |
machine |
dev3 |
tooling_profile |
dotfiles@4eac376 |
Search Terms
noEmit --build --dry,tsconfig.tsbuildinfo noEmit dry build,noEmit index.js does not exist dry build,build dry noEmit project references out-of-dateVersion & Regression Information
--build,noEmit, and project references.typescript@5.9.3.typescript@nextversion7.1.0-dev.20260717.1.tsgoversion7.0.0-dev+effect-tsgo.0.14.5.Playground Link
No Playground link. This requires a multi-
tsconfig.jsonproject-reference graph andtsc --build --dry.Code
tsconfig.json{ "files": [], "references": [ { "path": "./lib" } ] }lib/tsconfig.json{ "compilerOptions": { "noEmit": true }, "files": ["index.ts"] }lib/index.tsRun:
Actual behavior
The first dry run reports the referenced
noEmitproject as out of date because build info does not exist:A non-dry build creates
lib/tsconfig.tsbuildinfobut, correctly, does not createlib/index.jsbecausenoEmitis enabled:After that, repeated dry and non-dry builds keep reporting the project as stale because
lib/index.jsdoes not exist:This remains true after a second non-dry build:
It is not specific to
--noCheck;tsc --build tsconfig.json --dry --verbosereports the same missinglib/index.jsoutput after the project has been built.Expected behavior
Question: is this intended for
noEmitprojects in a--buildreferences graph?If this project shape is supported, I would expect build up-to-date logic not to require emitted JavaScript outputs for a project whose
compilerOptions.noEmitguarantees those outputs will never exist. After a non-dry build creates the relevant build info,--build --dryshould not report the project as perpetually needing a build becauselib/index.jsis missing.If this project shape is not supported, it would be useful for
--buildto report that directly rather than producing a perpetual stale-output result.Additional information about the issue
The same repro also appears in the TypeScript-Go port:
Posted on behalf of @schickling
agent_nameagent_session_idagent_toolagent_tool_versionagent_runtimeagent_modelruntime_profileskills_manifestworktreemachinetooling_profile