Should our watch process do more than just transpile?

[samreid]

I considered generalizing the transpiler watch process so that it triggers (a) transpilation (b) type checking and (c) linting, so we only have one file watcher total, and it can do everything we might want to do.

I have been running tsc --watch separately from transpiler --watch, so for my first consideration it would combine these. @pixelzoom also mentioned he has been running lint a lot, and I considered that it could also be put into a watch process with these.

[zepumph]

+1 for this work! I think that would make a lot of sense, and #1174 could be an awesome enhancement on this. If this was the case, could we have this be a grunt task? Can you watch from within a grunt task? Perhaps with grunt.task.current.async()

[samreid]

I have a concern that tsc --watch has optimizations beyond what we may get from running tsc over and over with incremental, and this seemed to match prior experiments. However, it is unclear whether that could be attributed to start up overhead or not. It would have to be tested. If our own tsc is slower than just running tsc --watch in parallel, we will have to weigh the benefits.

[samreid]

I found that tsc --watch is consuming a staggering 70% CPU when doing nothing (all built, no files changing).

[pixelzoom]

If you're measuring that with macOS Activity Monitor... In Activity Monitor, each core/hyperthread accounts for 100%. (Hyperthreading splits each physical core into 2 virtual cores.) This is why you'll frequency see %CPU values > 100%. So you're likely using 70% of 1 core. If you're on an M1 MacBook Pro (8 cores), I believe that's < 10% of the machine's potential.

[samreid]

Agreed, thanks.

@pixelzoom also said on slack:

For tsc --watch , I see 25.5% CPU on my 6-core MacBookPro16,1, and 54.35% CPU on my 4-core MacPro5,1 (when tsc is idle).

The near-0.0% CPU of node js/scripts/transpile.js --watch seems preferable to tsc --watch, so I'm somewhat more incentivized to work on that.

[samreid]

Maybe the transpiler process could also run update-copyright-dates, see phetsims/perennial#260

[samreid]

Recently the dev team has reported problems using tsc --watch -- false positives and false negatives, so it may not be suitable as a component for this system.

[samreid]

False positives and negatives may have been a result of the fact that we were not listing all transitives dependencies in each tsconfig, discussed in #1245. The solution for that issue was to get rid of project references altogether and use a more monolithic approach. I tried using tsc --watch on the monolithic approach and it took about 11sec to type check an added optional node option. That is the same as reported in #1241 (comment). So I will probably keep triggering tsc from a keystroke from the comfort of my IDE.

[samreid]

@zepumph previously expressed interest in adding features to this watch process. @zepumph does this still sound valuable to you?

[zepumph]

I think that our precommit hooks are in a good state. The only reason for a more comprehensive tool like that was to utilize the caching of type checking to speed up the hooks. This caching will occur now with our monolithic type checking. I'm ready to close this.