Guides - Improving Build Performance

[bebraw]

Stub.

Feel free to comment here if you have ideas on what this guide should cover. Link to potential resources too.

[yuridevx]

Brunch, for example, claims that they use caching and process only those files that were not changed. In addition to that I know that gulp if configured properly will process only changed files rather then reprocess all of the files in a glob pattern. When I've read webpack documentation I had no idea on how could I structure my build so it will be fast. Does it somehow optimize one .less file that includes all smaller once? etc...
In other words what are the best practices for fast builds in complex setups like typescript->es6->traceur-> webpack2 for tree-shacking. Or less->css->styles (with possible hot reload?)
Is there anything on this topic?

[yuridevx]

And what about different linting tools in the loader chain? How does that affect overall build/rebuild performance.
Is it better to not include them there at all?
Some time measurements would be cool in performance docs I think.

[bebraw]

Great ideas and topics to study. Thanks!

[yuridevx]

@bebraw I'm looking forward to become an open source participant. I would like to contribute perhaps I could do some kind of investigation and write about it.
The challenge is I'm new to the open source world as well as I'm new to the English documentation writing (not native speaker). Is there any way I might be helpful? If yes then could you give me advice on how to start with webpack docs?

[bebraw]

@yuridevx Language won't be an issue as long as the content is solid and well researched. If you can comment around at the issues and help to craft outlines, that would help quite a bit. We'll be developing the content based on this work.

I hope to make another, more focused blog post in two weeks after the direction is clearer and there's a site prototype to show.

[bebraw]

To quote @mover96 from #46.

Here is a great write up on a lot of the features of the DLL Plugin (I cannot figure out how to anchor to specific posts on bountysource, but it's near the bottom)

https://www.bountysource.com/issues/28615391-webpack-incremental-builds-are-slow

The biggest point for me is that it cannot be used with CommonChunksPlugin, but there is a lot of good information in the post as well!

Disclaimer: This is my first time submitting to webpack.io, let me know if there are certain conventions I should be following!

[vvo]

State:
The stub link you gave is no more working.
The current guide on performance is full of TODOS.

Some more info:

It seems in the webpack community people are using a mix of:

• happypack, loaders applied in a multi cpu way
• DLL plugin, split your code into moving and non moving parts
• babel-loader cacheDirectory: true
• only apply uglifyjs when NODE_ENV=production
• only generate hash files when NODE_ENV=production
• use fast source map solutions in dev (tradeoff), https://webpack.js.org/configuration/devtool/
• http://www.slideshare.net/trueter/how-to-make-your-webpack-builds-10x-faster

Happy perf! :)

[skipjack]

@vvo good catch -- I updated the link in that comment. By any chance would you be interested in taking a stab at completing that guide?

[skipjack]

@bebraw those links in @vvo's comment and the slideshare are a good start... do you have anything on SurviveJS already that deals with build performance? Maybe between that and the other information here we'd have a good start. #1337 removes the current stub as it's still all TODOs and makes our current review a bit easier but there's a few ideas there as well (if you view the history).

I'm not familiar enough with these optimizations to pick this up myself atm, so it would be great if someone else could dig into this!

[bebraw]

@skipjack I have one chapter on the topic.

[skipjack]

Ok great, I added the Help Wanted tag... hopefully someone sees it and has time to pick this up!

[vvo]

(if anyone starts this, please put a comment as I might do it "at some point")

[skipjack]

Closing thanks to @sokra with #1506 merged! 🎉 🎉

@vvo sorry I don't think he noticed this comment but please feel free to submit any follow up PRs if there's more content you think can be added or things that could be elaborated.