Skip to content
This repository has been archived by the owner on Jan 26, 2019. It is now read-only.

Support for fork-ts-checker-webpack-plugin / thread-loader #160

Open
johnnyreilly opened this issue Sep 12, 2017 · 1 comment
Open

Support for fork-ts-checker-webpack-plugin / thread-loader #160

johnnyreilly opened this issue Sep 12, 2017 · 1 comment

Comments

@johnnyreilly
Copy link

johnnyreilly commented Sep 12, 2017

Would you be interested in a PR that adds support for fork-ts-checker-webpack-plugin and thread-loader? I mention it as I'm about to start a new project and was planning to use this as my starting point. For now I'm planning to eject post create to add in fork-ts-checker-webpack-plugin and thread-loader as I like faster builds where possible. But I can see how this might generally be useful to users of this fine project. I'd be happy to submit a PR if that's interesting to you?

https://medium.com/webpack/typescript-webpack-super-pursuit-mode-83cc568dea79

FWIW I think support would simply be added by editing these 3 files:

Also, if you did decide this was interesting it also opens up a choice about tslint. The fork-ts-checker-webpack-plugin allows the option to run tslint for you as well as type checking. So you could (if you chose) remove usage of tslint-loader and just have fork-ts-checker-webpack-plugin do that job too. Or not - these are all choices 😄

@DorianGrey
Copy link
Collaborator

DorianGrey commented Sep 18, 2017

Since I've had some good experience using fork-ts-checker-webpack-plugin even for larger projects, I'd vote this up.
However, I'm not sure about the benefit of using thread-loader and cache-loader here:

  • On smaller projects, this setup would create an unnecessary overhead - a bit of an overkill.
  • On larger projects, it would be useful for speeding up transpilation times, but type checking is the more (time-) expensive part. Since the current create-react-app setup enforces using fork-ts-checker-webpack-plugin in sync mode, a rebuild will complete (and thus reload) only after both transpilation and type checking completed successfully. As a result, there is only a limited benefit of using a parallel build and caching.

€dit: Besides, this change would superseed PR #140, and even perform way better.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants