Twitter | Search | |
Gary Bernhardt
When I talked about how slow TypeScript is (e.g., ), I was told "just use a watcher!" But watchers literally don't work. For example!
Reply Retweet Like More
Gary Bernhardt Dec 12
Replying to @garybernhardt
Rollup's watcher (with rollup-plugin-typescript2) doesn't even notice file renames or changes to .d.ts files. In both cases, you have to kill and restart it manually. File renames are common, as are .d.ts files. This is not a reliable solution to the problem.
Reply Retweet Like
Gary Bernhardt Dec 12
Replying to @garybernhardt
Webpack's watcher (with awesome-typescript-loader) reports type errors when I switch from one branch to another. This continues to happen until I kill and restart webpack. Switching branches is common. This is not a reliable solution to the problem.
Reply Retweet Like
Gary Bernhardt Dec 12
Replying to @garybernhardt
File watchers are not a solution to the problem of fast builds. They are a trade-off you make to get faster builds *some of the time*. The other side of that trade-off is significantly slower builds at unpredictable intervals, plus occasional failures you don't understand.
Reply Retweet Like
Gary Bernhardt Dec 12
Replying to @garybernhardt
Whenever I tweet about this, people reply to say that oh, yes, *that* file watching tool is unreliable, but *this other one* one isn't! If I tweeted about Rollup being unreliable, people would recommend Webpack. If I tweeted about Webpack, people would recommend Rollup.
Reply Retweet Like
Gary Bernhardt Dec 12
Replying to @garybernhardt
There is one solution to this problem that has worked reliably: make the build process fast enough that you don't need the long-running build process. Go is fast enough; OCaml is fast enough. These are production-ready, not proofs of concept. The watcher hack is not necessary.
Reply Retweet Like
Gary Bernhardt Dec 12
Replying to @garybernhardt
This is all separate from dev servers that watch to reload on change. Of course you want that, regardless. But a build and restart is not inherently stateful! The state is the problem, and leaving the build tool running means a ton of complex state that's inevitably mismanaged.
Reply Retweet Like
Gary Bernhardt Dec 13
Replying to @garybernhardt
Just found a different Webpack+awesome-typescript-loader watch failure mode: Watch builds clean, but a plain `webpack` errors. I've only been using Webpack for 24 hours and this is the second huge bug that I've found where it misreports the correctness of the system.
Reply Retweet Like
Gary Bernhardt Dec 14
Replying to @garybernhardt
After 48 hours of Webpack, I now have three huge watcher bugs. The new one is that the reported line numbers for errors are wrong. But only sometimes. I've written production code in something like 20 languages and have never seen this happen in any programming tool, ever.
Reply Retweet Like
Gary Bernhardt Dec 14
Replying to @garybernhardt
(This one isn't directly related to watching, but it illustrates the same kind of disregard for correctness, which is a special property of JavaScript tooling as compared to (almost) all other languages.)
Reply Retweet Like
Gary Bernhardt Dec 14
Replying to @garybernhardt
I used to avoid Webpack etc. by running `tsc` directly, along with a 15-line custom module loading hack. I got a lot of extremely dismissive "just use Webpack" replies, including people telling me that I was making things hard. This thread documents what "easy" means to them.
Reply Retweet Like
Gary Bernhardt Dec 14
Replying to @garybernhardt
We now run both `tsc -w` and `webpack -w` in the same terminal, both backgrounded. I'm pretty confident in `tsc -w`'s ability to report errors, even when files are renamed, moved, etc. Though Webpack may still hose itself in those situations, requiring a restart. We'll see.
Reply Retweet Like
Gary Bernhardt Dec 14
Replying to @garybernhardt
I realize that what I actually want in this thread won't be obvious to people who are newer to Unix. Basically, I want my watcher to be this one-liner: fswatch -o src | while read; do tsc | es6-to-es3 | minify | write-file-with-content-hash 'dist/bundle-%s.js'; done
Reply Retweet Like
Gary Bernhardt Dec 14
Replying to @garybernhardt
p i p e s
Reply Retweet Like
Wilfred Hughes Dec 12
Replying to @garybernhardt
Watchers are orthogonal to build times, no? However fast a compiler is, having a watcher is nice. Why wait for the user to ask for a compile or a test run? Dev machines are often idle when the user is typing.
Reply Retweet Like
Gary Bernhardt Dec 12
Replying to @_wilfredh
They're not orthogonal, no.
Reply Retweet Like
Real AI Dec 12
they don't make the build time any faster or slow, they should be used for convenience, so you don't keep clicking build every time. So, they are orthogonal.
Reply Retweet Like
Gary Bernhardt Dec 12
Replying to @Luiz0x29A @_wilfredh
This implies that booting a program has no cost.
Reply Retweet Like
Wilfred Hughes Dec 14
Aha, I see why I misunderstood. I was thinking about any tool that automatically triggers a rebuild, whereas I believe you're describing a persistent *compiler* process. `while true; if changed(srcdir) do make; fi` would (crudely) meet what I had in mind.
Reply Retweet Like
Gary Bernhardt Dec 14
Replying to @_wilfredh @Luiz0x29A
Yep. I've done that before and it's great if the compiler is fast. But for TypeScript in our app, doing it that way means 4000-7000 ms instead of the 600-2000 ms it takes with `webpack --watch`.
Reply Retweet Like
Steven Dec 14
Replying to @garybernhardt
I have been using TS for years and I agree, the startup time is slow. Some of that time is npm if you are invoking “npm run build” and some of that time is webpack and the custom loader if you are using it. Do you have the same problems when directly using tsc --watch?
Reply Retweet Like
Gary Bernhardt Dec 14
Replying to @styfle
That's quite quick. But I don't want a watcher at all; I want a fast compiler.
Reply Retweet Like