Repository navigation
Incremental --build, then delete generated js file, then another incremental --build does not recreate js file #30602
Description
Activity
Hmm the root cause of this is that in general our incremental build (BuilderProgram) isn't equipped to deal with missing output file as indication to build but changed file as more like it. Need to think about what we can do here. Till then the workaround is to run --clean and then build or add comment or something into the file whose output needs to be generated.
Note that this didn't originate with just --incremental, this would be same behavior when you followed same pattern but were runningtsc --build --watchfrom first step (even without --incremental in compiler options)FYI Ryan Cavanaugh (@RyanCavanaugh) Daniel Rosenwasser (@DanielRosenwasser)
A separate, but possibly related issue: deleting source
.tsfiles does not remove the related.jsfiles. Right now, to address this, I clean the output directory before every compilation - but this makes it impossible for me to use the--incrementalflag.Reacted by Danny Hermes, Regev Brody, LeoTM, Jasper Roloff, Zhichao Wang, Alexander Alexandrov, amanofbits, Felix Schröter, John Meyer, jdt3969 and 23 moreIrakliy (@irakliy81) that's totally out of scope and does not work even without --incremental. Build cannot delete any output file unless you specify clean (which will also delete output files of config specified at that moment)
👍
Also experienced this bug:
We had a piece of code which imported a recently deleted file error in one of the dev-branches, and since we use caching of buildinfo in CI, parallel branch builds started to experience this missing file too. However, the error was different than just 'module not found', it was another type error from patient-0 branch.Sheetal Nandi (@sheetalkamat) - yes, I wouldn't expect it to work without --incremental flag since in that case there is no info stored about the previous build. But with the --incremental flag, it should be possible to remove output files if the source files have been removed.
A separate question: how do you specify
clean? It doesn't seem to be a valid compiler option.Irakliy (@irakliy81)
--cleanMiles Johnson (@milesj) - thanks! But it doesn't seem to be listed here: https://www.typescriptlang.org/docs/handbook/compiler-options.html and if I try to set it in VS Code I get "unknown compiler option" error. Am I missing something?
It's part of project references. Not sure if it's available outside of that, nor as a compiler option. https://www.typescriptlang.org/docs/handbook/project-references.html
any plans on fixing this? cc Sheetal Nandi (@sheetalkamat)
it kills the point of caching build info in CI
Reacted by Giancarlos IsasiFor clarity: What/who is deleting the output files and why?
There are multiple workarounds for this issue.
- Run tsc --b --clean
- Delete .tsbuildinfo file as well
Its not clear why only .js file is deleted
Reacted by LeoTM, ivanrakonjac and Listiani21 remaining items
This is a bit confusing.
- If we don't run with
--build, then thetscprogram completes very fast, with no clues as to why, as if everything is fine.- Running just
tscshould give a helpful message. Or, even better, it should run the project in--buildmode. - Perhaps we need an option in
tsconfig.jsonthat can make the--buildoption not required.
- Running just
- If we run
tsc --clean, it fails, without a helpful message. There's no obvious way to know that it should betsc --build --clean
It's just not intuitive. I think many people spend many hours (if not days) fiddling around with this stuff. It is too time consuming.
Reacted by InvictusMB, Felipe Torres (fforres), Lex Kuncevic, Matthias Günter and Gonçalo Tavares- If we don't run with
Should --incremental assume that some files may have been deleted from disk?
There's a real perf cost to doing this and it's unclear how you would often get in this state in a way where you couldn't automate yourself back into a good state (e.g., if a script is deleting some random subset of JS files, that script should also delete .tsbuildinfo and force a rebuild).
Experience report:
We are running into this in the context of converting one project in a monorepo from JS to TS. So we used to have an
index.jsin one of our libraries. I converted it toindex.tsand added abuildscript in the package.json. All contributors install all dependencies and run allbuildscripts anyway as part of the monorepo tooling, so I assumed that they would not see any difference. But when contributors switch back and forth between a branch that has my changes and a branch that does not have my changes,gitends up deleting theindex.jsbut not thetsconfig.tsbuildinfo. I think because the other branch hasindex.jstracked bygitbut nottsconfig.tsbuildinfo. So the end result of switching branches back and forth is that the build is broken and can only be repaired by cleaning.I saw a couple of colleagues complaining in Slack and was affected myself, so I guess that more colleagues were affected but didn't complain. I estimate we lost about 10 person hours because of this, plus some confidence in typescript. (Personally I'm still confident in typescript, but some colleagues had a first bad interaction now).
Reacted by Lorenzo Dalla Vecchia, Victor Musienko and Petr VilímWe are having problems similar to Tillmann Rendel (@Toxaris)
Sometimes,tscstop recompiling some files, assuming that they are unchanged. The only way to recover is to force a change in the affected file or delete the.tsbuildinfofile.
In our case too, it seems to happen when switching branches or rebasing.I have also tried looking into the
.tsbuildinfocontents, but I don't know how to interpret them.
Is there a strategy we can use to pin down the problem?Reacted by christhegrand- added a commit that references this issue
on Jun 16, 2021 Should a subsequent build delete files that were generated by a prior build but no longer have a source?
Yes, yes please. In our use case we compile migration files to a directory and all files in this directory are evaluated when the migrations run. We have had issues where checking out to feature branch A, testing the feature, reverting the migrations and checking out to feature B, preserves the migrations of feature A. This harms developer experience because our developers need to keep track of any compiled files that might linger from other branches.
IMO an incremental build should take the output folder from the current state to the desired state while using
.tsbuildinfoto speed up the process and only build when necessary. Running an incremental build should produce the same result as removing the output folder and running a normal buildReacted by Adriano dos Santos Fernandes, Marwane Kalam-Alami, Tillmann Rendel, vidal7, Tigran, LeandroDG, Petr Vilím, Eric Crosson, Ron B. Yeh, matthewbaker-auditboard and 7 moreFor "should a subsequent built delete files that were generated by a prior build but no longer have a source?", #16057 is closely related (with several links to libs that patch in this behavior).
Running an incremental build should produce the same result as removing the output folder and running a normal build
I strongly agree with this statement!
At the moment, incremental builds provide maximum performance but with the possibility of "incorrect" or unexpected output (i.e., it does not build a file we expected it to build).
I'd rather the incremental build always be 100% correct. It should still be faster than a full clean and build, since it can skip the compilation of some modules.
Maybe we need a different flag that guarantees correctness, but with a slight performance penalty?
"compilerOptions": { .... "incrementalSafe": true }Reacted by Felix Leupold, Zeno Wu, James Newell and Xavier RuizSafety should be opt-out, not opt-in.
Reacted by Xavier RuizSafety should be opt-out, not opt-in.
I agree, but since this issue has been open 2 years, I was hoping to suggest something that might be accepted, so those of us who care can use the safer option.
Ideally, the
"incremental" : trueshould guarantee correct output, and we can have more advanced options to adjust the build speed / safety if desired, like:"compilerOptions": { .... "incremental": { "checkMissingOutputFiles": true, // output *.js file disappears => rebuild it on the next pass. default: true. "checkMissingSourceFiles": true, // source *.ts file disappears => delete the associated output file on the next pass. default: false. "checkModifiedOutputFiles": true, // output *.js file modified => rebuild it on the next pass. default: true. "checkModifiedSourceFiles": true, // source *.ts file modified => rebuild the output file on the next pass. default: true. This flag can obviously be omitted, as it's implied by "incremental compilation". If we set it to false, incremental wouldn't work! :-) } }The default values were chosen because they are safest:
checkMissingOutputFiles=>truecheckMissingSourceFiles=>falsecheckModifiedOutputFiles=>true
Reacted by Wojciech Pawlik, Tillmann Rendel, Dylanlan, Vincent Taverna, Skylar, Jason Siefken, Clément Nerma, Sebastian Goll, ecoms-ye and Gonçalo TavaresI just got hit by an issue from a renamed source file, where the old output JS file ended up getting executed instead, and had a runtime error.
I think my case was specifically the
Should a subsequent build delete files that were generated by a prior build but no longer have a source?issue. But it sounds like the general issue at hand is from trying to keep the source and output files in sync (kind of similar to cache invalidation?)I'm a fan of having configuration options for correctness / speed tradeoffs if possible.
In my opinion, it should guarantee correctness by default, but configuration options to toggle would be awesome.It sounds like there's multiple ways for the compiled output directory to get out of sync with the source, where incremental builds won't re-sync. This makes incremental builds less valuable for me, by not being able to trust whether the output directory is in the expected state or requires some manual inspection / fixing.
My understanding of some current workaround options are:
1. Manually delete the outDir &.tsbuildinfowhen I run into an error (my current approach, but might be non-obvious if an error is related or not)
2. Write my own custom logic to identify if the outDir has gotten out of sync (seems fairly complicated to me)
3. Always delete the outDir &.tsbuildinfobefore incremental compilation (removes most of the benefit of incremental)I'm curious if there's any other good workarounds!
Regarding precedents for deletion, I'm familiar with some related config flags in a couple other tools.
But they're specifically for source to target directory sync, rather than incremental compilation:rsync --delete:delete extraneous files from dest dirsaws s3 sync --delete:Files that exist in the destination but not in the source are deleted during sync.
Reacted by Ramy El Khayat and Sebastian GollHi,
I just found the same problem on my NestJS project and lost more than one hour to find the cause of this.
Here is the process with a very simple typescript project to reproduce it easily :- Create a "test" folder, go inside on a shell, and type the command : npm i typescript --save-dev (very simple "package.json" and "package-lock.json" files are created, defining this only dev dependency)".
- Type the command: npx tsc --init (a "tsconfig.json" is created).
- Modify the "tsconfig.json" contents with this:
{ "compilerOptions": { "module": "commonjs", "baseUrl": "./src", "rootDir": "./src", "outDir": "./dist", "target": "es2017", "incremental": true } } - Create a "src" subfolder in your "test" folder, owning a simple "test.ts" file defining a simple class:
export class MyClass {} - Build the project by typing in the "test" folder the command: npx tsc -p tsconfig.json
- The "test/dist" folder is created owning only one file "myfile.js" defining the MyClass class. But a "tsconfig.tsbuildinfo" file has also been created NOT into the "dist" folder like the documentation explains, but in the "test" folder at the same level than the "tsconfig.json" file.
- Delete the "dist" folder and build the project again with the same command than the step 5 above.
- The "dist" folder is NOT generated this time, and the tsc command returns no error (code returned is 0).
IMPORTANT: NestJS set this "incremental" property to "true" by default in every new NestJS project. This is how I got the problem. For several days I got no problem: the "tsconfig.tsbuildinfo" file was generated inside the "dist" folder. But at a certain moment, I should have set a bad config because I did several configuration tests, and the "tsconfig.tsbuildinfo" has been generated in the main folder of the project as in the above example, causing the problem.
The only bypass I see:
- Delete the "tsconfig.tsbuildinfo" file if it is generated inside the main project folder, instead of inside the generated "dist" folder.
- Or simply unset the "incremental" option, or set it to false.
Typescript version: 4.8.2
OS: Windows 10
Shell: Command Prompt (DOS)Regards.
Should --incremental assume that some files may have been deleted from disk?
My use case for having the
--incrementalflag check the existence of "outputted" files on disk is that I have multiple tools building into the same folder and I would like to delete the build folder between builds.e.g.
{ "scripts": { "clean": "rm -rf dist", "build": "npm run clean && npm run build:js && npm run build:types && npm run build:files", "build:js": "swc src --outdir dist", "build:types": "tsc --declaration --emitDeclarationOnly", "build:files": "cpx src dist --ignore *.ts" } }The reason I would like to clean between builds is because files might have been deleted since the last build and not removing them increases the size of the build artifact, is confusing to debug and can result in unexpected consequences during execution - e.g. move
foo.tstofoo/index.tsand nodejs will still require the old generated artifact.I was hoping that
--incrementalwould save the compiler from a notable amount of work, even if it did mean writing the output files again.Similar to other posters it took me a while to understand what was happening and finally end up here 😄
One scenario in which output files may be removed is when publishing a package that uses
"declarationMap": true. In that case, the generated.d.ts.mapfiles should not be included in the published package, since the original source will not (in general) be available.And since
package.jsondoes not have a syntax to exlucde files from the tarball when using the"files"field, I think TypeScript should consider either implementing this feature or provide an option to generate declaration map files in a specific folder (e.g.,"declarationMapDir").I'm seeing similar behavior when running a build doesn't output a new build (I use incremental as well). Deleting the tsbuildinfo does fix this. However I found that the issue I had was using "emitDecoratorMetadata" in the tsconfig for our decorators. This for some reason prevents 'build' from re-generating the build output correctly.
Reacted by vidal7- added a commit that references this issue
on Mar 8, 2026
TypeScript Version: 3.4.0-dev.20190326
Search Terms:
incremental
Code
tsconfig.json:
{ "compilerOptions": { "incremental": true } }x.ts:
Expected behavior:
$ tsc --buildx.jshas been generated$ rm x.js$ tsc --buildExpected: x.js has been regenerated
Actual behavior:
x.js still does not exist
Related Issues:
Did not find any.