Open flut1 opened 5 years ago
@hjeti I will take care of this if you like. Do you happen to know why we have node_modules
in the "include" array of tsconfig.json
? This will most likely slow down compilation a lot. These are the only files you would want in that includes array:
definitions.d.ts
file.While I don't think that it matters much to include our entire src
folder (we probably use all these typings anyway), there are potentially a lot of .ts files in node_modules that are irrelevant to our projects.
I believe WebStorm likes to have the full src/**/*.ts
in there to enable project-wide type checking, it doesn't follow imports itself.
Yeah I think what I said about the entry point might be true for the files
array rather than include
. Regardless I agree that we should keep "src/**/*.ts"
. In my experience it's really annoying if Webstorm doesn't pick up your new TS files unless you import them from somewhere.
That does still leave node_modules
however, which we should probably remove.
I ran into the following issue on a different project: s-panferov/awesome-typescript-loader#528
Will need to investigate either adding fork-ts-checker plugin like the comments suggest, or maybe look into using ts-loader instead
@flut1 I don't remember why I added the node_modules.
If we are going to move away from awesome-typescript-loader maybe we can use the babel typescript preset in combination with the fork-ts-checker-webpack-plugin. I don't know how stable it is but it is used in create-react-app.
I think I'll have to try both ts-loader, awesome-typescript-loader and babel-typescript in 1 or more projects to see which is fastest. I'll do some benchmarks and will let you know. Additional caching like hard-source-cache-loader seems to make a huge difference in all 3 of these.
See: https://github.com/s-panferov/awesome-typescript-loader#performance-issues
These settings should speed up compilation. (we should only enable caching for development)