Use new watch API in fork-ts-checker-webpack-plugin

[johnnyreilly]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

Fine

Expected behavior

Could be faster.

Minimal reproduction of the problem with instructions

N/A

What is the motivation / use case for changing the behavior?

Faster builds

Environment

Others:

This isn't a bug report - more a heads up. There's a new feature been added to the fork-ts-checker-webpack-plugin. This feature speeds up incremental compilation.

More details can be found here:

https://blog.johnnyreilly.com/2019/01/typescript-and-webpack-watch-it.html

Would you consider upgrading to this for the performance improvement?

See also: TypeStrong/fork-ts-checker-webpack-plugin#198
And: TypeStrong/fork-ts-checker-webpack-plugin#196

cc @jantimon

[jantimon]

Wow! Really nice 👍

Is there already a release plan for 1.0.0?

[johnnyreilly]

To quote myself 😉:

Anyway, you might be thinking "wait, just hold on a minute.... he said @next - I am not that bleeding edge." Well, it's not like that. Don't be scared.

fork-ts-checker-webpack-plugin has merely been updated for webpack 5 (which is in alpha) and the @next reflects that. To be clear, the @next version of the plugin still supports (remarkably!) webpack 2, 3 and 4 as well as 5 alpha. Users of current and historic versions of webpack should feel safe using the @next version; for webpack 2, 3 and 4 expect stability. webpack 5 users should expect potential changes to align with webpack 5 as it progresses.

So yeah - 1.0.0 will be whenever webpack 5 finalizes. But for webpack 4 (what this plugin uses) you're safe to use now.

[jantimon]

From TypeStrong/fork-ts-checker-webpack-plugin#196 (comment)

1. Parallelism. If we try to distribute incremental changes across different processes, there may be some errors missed - in case when changed files depend on one another.
Because of that I cannot even imagine how would it be possible to run incremental watching in parallel. On the other hand, it runs REALLY fast even for big codebases. (try 'yarn watch' workflow with vscode repository, for example).

Right now we use 2 workers for the fork-ts-checker-webpack-plugin during development.
Should we set it to 1 if we use useTypescriptIncrementalApi?

2. Vue files. For now I completely ignore them in my implementation. I could imagine a solution for that though: since we intercept all filesystem calls we could make TypeScript think those files only contain TypeScript code :)

Is that still true or does it work for vuejs files too?

[johnnyreilly]

Right now we use 2 workers for the fork-ts-checker-webpack-plugin during development.
Should we set it to 1 if we use useTypescriptIncrementalApi?

Yes - the plugin will intentionally throw an error if you try to use more than 1

Yes it works for Vue files 😁

Also: vuejs/vue-cli#3295

[jantimon]

Perfect - thank you so much 🎉

[jantimon]

Current state:

fork-ts-checker-webpack-plugin@next uses a node 8 only internal for performance timing.

So our unit tests fail:

However @johnnyreilly is working on a solution so we will be able to use it even for node 6 🎉

Side note: I would highly recommend to use a higher node version in your projects however as long as node 6 is the official supported webpack 4 version we should also try to achieve the same for the webpack-config-plugins to be compatible