tsc --build --watch (with or without --incremental) touches all files causing problems for downstream tooling

[jfstephe]

Bug Report

🔎 Search Terms

touch watch timestamp

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about timestamp/touch

⏯ Playground Link

N/A

💻 Code

tsc --build --watch

🙁 Actual behavior

Given a TSC output including:

-rw-r--r-- 1 root root 28561 Nov 3 13:25 app.js
-rw-r--r-- 1 root root 11643 Nov 3 13:25 app.js.map

Change a single file that isn't app.ts results in:

-rw-r--r-- 1 root root 28561 Nov 3 13:37 app.js
-rw-r--r-- 1 root root 11643 Nov 3 13:37 app.js.map

This completely kills downstream tools (e.g. the karma testing tool, when it is watching the output) that are watching the files for changes. Yes these could do a better job but the cause just seems so unnecessary and avoidable (especially with the --incremental option!).

🙂 Expected behavior

-rw-r--r-- 1 root root 28561 Nov 3 13:25 app.js
-rw-r--r-- 1 root root 11643 Nov 3 13:25 app.js.map

Changes to TS files don't result in any changes to any JS file that didn't have it's TS file changed

-rw-r--r-- 1 root root 28561 Nov 3 13:25 app.js
-rw-r--r-- 1 root root 11643 Nov 3 13:25 app.js.map

I've tried with and without the --incremental flag and no joy.

[andrewbranch]

It’s not unnecessary: 7b290fd

Update the timestamps of outputs that dont need to be written because of incremental build

This ensures that after tsbuild after incremental build of tsbuild -w doesnt result in unnecessary rebuilds

Sounds like this is used to tell future invocations of tsc that outputs are up-to-date, allowing work to be skipped.

[jfstephe]

@andrewbranch thanks for responding.

I'm not disputing that this is how it works, merely that perhaps there are better ways that don't affect downstream operations.

This issue definitely exists. tsc may be working as intended, but not as it is needed to or IMHO should.

Could the incremental data not contain information to remove the need to do this (for example)?

[andrewbranch]

e.g. the karma testing tool... Yes these could do a better job

I’m curious if you’re having issues with anything besides Karma. Also what does it mean for them to be “completely killed”?

[jfstephe]

Hi, yeah I should have elaborated.

Karma watch seems to be based on timestamps, so when one typescript file changes, tsc --watch touches all files and then karma change notifications happen for ALL files (this is really, several minutes sometimes, slow).

I completely understand that karma should be better in this, however the root cause as I see it is that tsc shouldn't be touching files that it doesn't need to. There may be several other tools that have this same problem.

[andrewbranch]

We’ve opened #46677 to track experiments with this. It may be a while before we can get to it, so I would encourage you to subscribe there (@typescript-bot will eventually close this issue). We’re unfortunately at a temporary shortage of people who have a deep understanding of our watch/build/incremental mode stuff, but it’s something we know we need to give more attention to when we can. I just wanted to convey that this is expected behavior for now, but we’re listening to feedback, but also you may want to investigate some workarounds in the short term. Thanks for understanding!

[jfstephe]

Awesome thanks.

[jfstephe]

Please also note that we are running on docker which is I suspect a contributing factor to the performance issue for downstream tooling.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.