You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In tsc --build while determining upto date ness status, we now check if referenced projects have errors so that we dont need to go through input and output timestamps in that case
During watch especially during polling file watch and in some scenarios during native file-system based watch we stat on files and that time is now passed through as part of file watcher event so tsc --build can use it.
Apart from this in watch mode we save timestamps for all the watched files. These get updated through watcher event callback or are repopulated if watcher event didn't query the time. So if 2 files changed out of 20 input files then at max we will requery timestamps for those two files (if watch callback didn't already give us updated time) FixesBuild mode explicitly checks file stamps in watch mode rather than using file watcher events #45082
If its incremental build, tsbuildInfo alone determines upto date ness of the build. For this we now store changeFileSet, dtsChangeTime and emitSignatures for the output files in the buildInfo when in multi file emit scenario.
We store fileVersions, outSignature, dtsChangeTime in single file output scenario.
The emitSignatures and outSignature are the d.ts hash of the output that last changed to the disk. Since any composite project already has declaration as must we can store this easily and save having to read files on emit to see if the d.ts file has changed. This makes sure that whether you are in tsc --build or tsc --build --watch mode the state is persisted so we know exactly if we need to really build or just update timestamps.
In case of multi file emit scenario, tsbuildinfo timestamp, changeFileSet and errors in the buildInfo determine whether we need to rebuild project or not. This way we dont have to update timestamps for anything except buildInfo when thing appear uptodate but timestamp doesnt reflect that. (eg upsteam project changed but didnt change d.ts files)
In case of single file emit scenario, tsbuildInfo timestamp is enough because we cant emit tsbuildinfo without emitting other output files.
Earlier we checked input file timestamps and found newest file, now in case of incremental build, we first check buildInfo as missing it, or errors is clear indication of requiring rebuild. After that we check each input file timestamp against buildInfo so that the number of checks can be smaller.
In non incremental project, we still need to update timestamps for output files that didnt change as there is no other way to tell if project is upto date or not. But we dont need to read d.ts files to see if .d.ts files have chaned since these projects cannot be referenced by other projects. (composite also means incremental which is must for referenced proejcts)
With so much depending on buildInfo, it is now cached and passed through emit as additional data so we dont have to reparse the json or identify which file is tsbuildinfo
We store the hash of files written in bundle emit to ensure that when we try to manipulate the sources for pseudo update (because d.ts of referenced project didnt change so only prepends need to concatenated in right order), we can check if file hasnt changed. This is now needed because bundle buildInfo also stores .d.ts change time and if incremental was toggled between compilations we might use wrong file text and get incorrect d.ts Look at 62c687b for details and 62c687b#diff-6b83fa9d09e38f88c61b24a70aec8668c68e0d8322e8404dbd85c90120f14eeeL1016 shows test that failed without this change
In builder, earlier we use to copy too many structures as part of backup which is internal method to ensure we can restore state if declaration emit fails. So now we are only storing emit state instead of reference map etc
Other change in builder is that earlier we use to maintain new delta of changes for affected files new signatures as well as new exported modules map. We use to commit it once all the affected files for the changed file is handled. (This was due to our API usage where we could cancel the operations in between and would still need to be able to reuse the state as much as possible). Now i have changed this to instead maintain copy of old signatures and old export map so that all we do is clear these these maps instead of having iterate through each and update them into the latest copy on commit
@amcasey@andrewbranch i have highlighted important commits and the change in the description and also have left some comments during the change. Let me know if you need more details.
This PR is basically aggregation of lot of changes that mostly needs to be together.. So minor refactoring can be a separate PR but rest needs to be together for everything to work so cant make this into smaller PR.
@sheetalkamat That table's great! When you ran those scenarios, did you do any checks to determine whether the output was the same as before? Also, do you have a similar (or simpler) table for compiling TypeScript itself?
The reason will be displayed to describe this comment to others. Learn more.
Your offline explanation made sense and I appreciate your thorough perf testing. I added some notes on naming and comments, but mostly I think we should check this in ASAP and see what happens.
I think this might have caused a regression. In my project, when I introduce errors and build with tsc -p, I get errors, as expected. When I build with tsc --build, it exits very quickly, and shows no errors.
λ ./tools/tvui/node_modules/.bin/tsc -p packages/tsconfig.json
# ... expected error messages omitted
Found 3 errors in 3 files.
Errors Files
1 node_modules/relay-hooks/lib/RelayHooksTypes.d.ts:56
1 packages/@tvui/fx2-transition/src/utils.tsx:173
1 packages/@tvui/redux/testing/unitTestingEnhancer.ts:8
tvui on nth/ts-4.8 [!⇡] via v16.16.0 took 10s
λ time ./tools/tvui/node_modules/.bin/tsc --build packages/tsconfig.json --verbose
[3:52:58 PM] Projects in this build:
* packages/tsconfig.json
[3:52:58 PM] Project 'packages/tsconfig.json' is up to date but needs to update timestamps of output files that are older than input files
________________________________________________________
Executed in 550.41 millis fish external
usr time 437.83 millis 50.00 micros 437.78 millis
sys time 194.10 millis 616.00 micros 193.49 millis
--build does seem to be faster, but perhaps it's so fast that it's not doing any work. 😄
I noticed this when doing the TS 4.8 upgrade. I observe this with version 4.8.2.
I'm happy to open a new issue for this if that's preferable.
I first noticed this after using yarn to update type-fest in node_modules.
I'm happy to open a new issue for this if that's preferable.
New issue is definitively better, check if there is no similar issue.
If you have a standalone minimal project to reproduce it will be gold for maintainers 🤗
Thank you!
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Commits: 16cef4a, 59ad6ef, c8327da
tsc --build
and other scenarios where we would do existence check as well asstat
which resulted in two stat calls, we just check modified timeCommits: cb7aca3
tsc --build
while determining upto date ness status, we now check if referenced projects have errors so that we dont need to go through input and output timestamps in that caseCommits: 89d2d4c
stat
on files and that time is now passed through as part of file watcher event sotsc --build
can use it.Commits: 6e0c916
Fixes Build mode explicitly checks file stamps in watch mode rather than using file watcher events #45082
Commits: 7cb0f40, 1a8abac, 59f2b5c, dc21283, 5bccee8,
tsbuildInfo
alone determines upto date ness of the build. For this we now storechangeFileSet
,dtsChangeTime
andemitSignatures
for the output files in the buildInfo when in multi file emit scenario.fileVersions
,outSignature
,dtsChangeTime
in single file output scenario.emitSignatures
andoutSignature
are the d.ts hash of the output that last changed to the disk. Since any composite project already has declaration as must we can store this easily and save having to read files on emit to see if the d.ts file has changed. This makes sure that whether you are intsc --build
ortsc --build --watch
mode the state is persisted so we know exactly if we need to really build or just update timestamps.Commits: 2f2e370, fcf07f8, 15fe24e
composite
also meansincremental
which is must for referenced proejcts)Commits: 6198fa3,
Commits: 62c687b
Commits: 4fb6773
Commits: 0f7903d, 437619e
BuilderState
,BuilderProgramState
etc structures so its correctly reflected.Commits: e6a3ee8
tsc --build --force
now doesnt query input file stamps (it never did query output file stamps)Commits: b32d2eb
Commits: 303824e
Commits: 28a9ff3
tsc --build
if file timestamp is changed but its text has not, we read the file and do pseudo update (only in incremental build).Commits: e4e6672 - Delete only tsbuildinfo instead of all output files when doing clean on incremental projectHere are the numbers from run on solution with large (1994) number of projects.
On Typescript Code base: