Improve Compile Times

[gonzofish]

Feels like the testing & dev-server experiences are too slow. Look at other projects to see how they are handling TS compilation and update the project to improve compilation time.

[tobi-or-not-tobi]

I just read through a few other issues and saw your note about priorities. Just want to let you know that the build performance is something that really bothers me. It feels a bit going back a year (when the angular cli was building very slow as well). I'm afraid I'm not keen enough on the topic to help out or give valuable pointers. I did a bit of reading last week, but realized I'm not close enough to this area.

[gonzofish]

I couldn't agree more with you. And appreciate the honesty about not knowing--I'm right there with you. I spent a couple hours last week on this and got nowhere. I should've mentioned this on that list of priorities, as it is a HUGE priority.

[tobi-or-not-tobi]

I'm spending some time on this tonight and I'm getting somewhere. My lib and example build time during dev watch have went down from ~10s to ~250ms. Pretty great, I'm however not sure (a) which of my changes lead to the massive dropdown and (b) whether I'm going to face any issues later on. Keep you posted, will do a pull request as soon as I'm having something stable.

[gonzofish]

Wow, awesome! Thanks a lot @tobi-or-not-tobi 👍

If you figure out what it is, make a PR and I can help you contribute your findings back.

[tobi-or-not-tobi]

After doing a bit more testing it really comes down to changing the creation of sourcemaps. The current value for devtools (devtool: 'source-map) is considered very slow. The webpack documentation shows the different values and their impact on performance.

My testing shows that the initial start takes still some time, but after that the build in watch mode shows numbers < 300ms. Only the very first change in an html component template takes roughly the same amount of time as the start up. Probably related to caching, although I don't recognize that from working with the angular cli.

I would go for eval or cheap-module-eval-source-map by default and add a note to the documentation of angular-librarian for developers if they need to switch to a different source map quality.

[gonzofish]

I think the cheap-module-eval would probably be good! Great work!

[gonzofish]

Just tested it out with some unit tests myself and wow is that faster!

[gonzofish]

so this fix is great for runnin the dev server, but it unfortunately does not apply to unit tests. while it makes the tests MUCH faster, karma-webpack has issues with outputting sourcemaps unless you use inline-source-map.

so for now the fix will just be for the npm start/webpack.dev.js

[gonzofish]

@tobi-or-not-tobi do you want to fork & add this fix? it's a pretty simple one, so it'd be a good/easy fix to contribute--if you do, I can point you to the exact place to make the change

if not, that's cool, too. just figure i'll always give someone the opportunity to turn their commit graph green 😉

[tobi-or-not-tobi]

Thanks @gonzofish I'll give that a try :)

[gonzofish]

Although #44 fixed the server performance, I'm keeping this open to see if I can fix test performance will keeping sourcemaps--might forgo it for now, but still worth investigating

[gonzofish]

Leveraging @tobi-or-not-tobi's suggestion, I've changed around webpack.test.js so that it exports a function that takes a boolean watch parameter.

I also updated tasks/test.js so that the we pass in a watch boolean when grabbing Webpack config for testing. So from now on headless tests should work much faster and watch tests (for now) are just going to be slow (😒).

Also, under this investigation, I discovered that sourcemaps when testing were messed up because of the tsconfig.test.json file doing inlineSourcemaps & not doing sourceMaps...

[gonzofish]

Closing since tests should be faster with f2fe239