Repository navigation
.tsbuildinfo file should be created when the noEmit flag is enabled #30661
Description
TypeScript Version: 3.4.0-dev.20190330
Search Terms: incremental, noEmit, no emit, tsbuildinfo
Code:
https://github.com/vkrol/typescript-incremental-no-emit
{
"compilerOptions": {
"outDir": "./dist",
"incremental": true,
"noEmit": true
}
}Expected behavior:
.tsbuildinfo file should be created when the noEmit flag is enabled.
Actual behavior:
.tsbuildinfo file is not created when the noEmit flag is enabled.
Activity
[-].tsbuildinfo file should be created when the noEmit flag is enabled.[/-][+].tsbuildinfo file should be created when the noEmit flag is enabled[/+]OliverJAsh commentedon Apr 1, 2019
This would be useful so we can still benefit from fast rebuilds when using
tscfor type checking only.sheetalkamat commentedon Apr 1, 2019
Though emitting a file (in this case .tsbuildinfo) when
--noEmitis specified seems inappropriate.cc: Daniel Rosenwasser (@DanielRosenwasser) and Ryan Cavanaugh (@RyanCavanaugh) for their input.
denis-sokolov commentedon Apr 1, 2019
The way I use these terms, “emit” refers to the valuable output of the application, something we’d put to stdout in unix terms. The tsbuildinfo file is a cache that is supposed to be invisible to the consumer. The fact that it happens to be a file that we happen to write to disk is rather an irrelevant implementation detail.
RyanCavanaugh commentedon Apr 1, 2019
"tsc emits anything when
--noEmitis specified" is a follow-up bug report to this one.The problem here is that
incrementalis on by default ifcompositeis on, so this is an actual risky change because it's going to mean new build artifacts in unexpected places for people using--noEmittoday.If the build info file path is specified manually, then writing it out does seem OK
denis-sokolov commentedon Apr 1, 2019
It tsbuildinfo a build artifact in an unexpected place, though? What if we write this cache to /tmp, the Windows registry, or whatever other storage, as long as the user does not see it? (edit: to be clear, the previous sentence is a hypothetical to help identify the meaning of tsbuildinfo, not a real suggestion) It seems like the explicitly thorough solution would be to split the
noEmitoption intotypecheckButNoBuildOutputandnoTouchingMyFilesystem.vkrol commentedon Apr 2, 2019
Good idea 👍
Merge branch 'TS34'
fmal commentedon Apr 4, 2019
Ryan Cavanaugh (@RyanCavanaugh)
i second this!
META-DREAMER commentedon Apr 17, 2019
This would be incredibly useful in react native since the typescript code is parsed with the packager using Babel 7 so for type checking we have to use
tsc --noEmitvaskevich commentedon Apr 26, 2019
I was looking into just ditching the
--noEmitflag in order to use--incremental, but even though the subsequent build times decreased by half, the initial build time went up by quite a bit due to emit time.I'm not super familiar with the implementation, but it seems like type checking via
--noEmitshould still be able to benefit from the signatures/dependencies stored in the build info cache file, and this would be great for use cases like speeding up type checking in CI by caching and reusing the build file periodically.zen0wu commentedon Jun 1, 2019
+1. I'm temporarily setting
outDirto a phantom folder just in order to thetsconfig.buildinfoemitted to speed up the compilation!Context: It's a frontend project with webpack+babel so emitting js is not useful.
11 remaining items
chore: speed up tsc
liana-p commentedon Mar 26, 2020
Just want to add to this, has any solution been reached for this issue? More and more people are switching to using babel to remove typescript and checking types with
tscon the side, but we then lose the advantage of incremental builds which isn't great.wincent commentedon May 17, 2020
So it seems that people who are using
tscjust for type-checking (ie. with--noEmit) want to make it faster by being able to add--incrementalas well.I'd just like to point out that you can run into this problem from the other direction too: ie. you already have
"incremental": truein yourtsconfig.json(for speed), and you decide you want to be able to do a typecheck alone (ie. not write any output). Discovered this because my editor does atsc --noEmitwhen you ask it to do a typecheck-only run.Even if you wanted to forgo the speed benefits of
"incremental": truefor this use case, you can't turn it off temporarily because there is no--noIncremental(or analogous) flag. One workaround is to remove"incremental": truefrom yourtsconfig.jsonand start passing--incrementalonly when you're doing an actual build and--noEmitwhen you just want to do a slow type check. As suggested above, setting a scratchoutDirworks too.fix(vim): make :Typecheck work in presence of `"incremental": true`
InExtremaRes commentedon May 17, 2020
Greg Hurrell (@wincent). There is no
--noIncrementalbut you can pass--incremental false:wincent commentedon May 17, 2020
Thanks Daniel Contreras (@InExtremaRes), that's easier than
outDir.minedeljkovic commentedon Jun 26, 2020
Sheetal Nandi (@sheetalkamat) is this also fixed in #39122 ?
sheetalkamat commentedon Jun 26, 2020
Yes
OliverJAsh commentedon Aug 10, 2020
I just upgraded to TS v4 to try this out. Previously we were just using
noEmit, now we're usingnoEmit+incremental.It seems that
tscis a lot slower when we runnoEmitwithincrementalas opposed to without.Stats from the
diagnosticsflag:noEmit: 15s check time, 0s emit timenoEmit+incremental: 15s check time, 160s emit timeI'm assuming this is intended but does anyone understand why this is the case?
sheetalkamat commentedon Aug 10, 2020
Oliver Joseph Ash (@OliverJAsh) Seems like declaration emit in your example takes longer.
try tsc --dand you should see similar behavior. There are multiple issues tracking different declaration emit being slow and their workarounds that lookup and if something new, please create new issue with repro details.evelant commentedon Aug 14, 2020
Sheetal Nandi (@sheetalkamat) I also tried this out and it doesn't seem to create a tsbuildinfo file at all using Webstorm 2020.2 with
noEmitincrementalandtsBuildInfoFileset.vaskevich commentedon Aug 23, 2020
I wanted to propose a follow-up change to this: #40198