Having to find it on gist because the official documentation is so lacking that nobody can figure out how to configure the thing except by following examples is the main problem that leads people to fear webpack configuration and to cargo cult magical config files that they are afraid to touch.
Mature tools can be understood in principle and configured without needing to see "how someone else did it."
The recent rewrite of the doc seems pretty clear and straightforward to me. Did you take a look at it?
I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again.
> I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again.
And that's a valid audience for the tool.
Good documentation would support this audience too, with plenty of examples and recipes. Even a repository of documented common use-cases (which must exist for Webpack's automated testing, right?)
I looked at the documentation the last time there was one of these complaints about webpack threads, the usage and benefits of loaders, plugins and modules seemed hard to understand as opposed to gulp where you just have a pipe.
I don't care if I can just plop a simple webpack without thinking in and it will handle everything I need, because I will always need more - and besides which I have my own gulp files I can just plop in without thinking too because I wrote them and I know exactly what will happen.
It's much much better, but still not very clear in many places. Just the other day I was struggling to figure out what some magical terms were referring to.
Thats surprising to me. Even the originally 1.X documentation wasn't that bad for the common cases. The 2.X documentation is pretty darn good.
The only issues I hit back then was complex cases back in the 1.X days. But if all you wanted was an app with prod/development mode that compiled javascript, css, let you import assets, minify in production and hash file names for long term caching, it's pretty simple considering everyone wants these to work slightly differently.
> Mature tools can be understood in principle and configured without needing to see "how someone else did it."
I don't know a more "understood in principle" tool than Webpack. There are no magical invocations just `webpack` and you are done. Plugins are usually just a require and adding to your plugins array.
I also think the maturity of a tool is in being easily understood just by reviewing someone else's config. To me, that speaks volumes for how simple and easy it is to get up and running in webpack.
Having to find it on gist because the official documentation is so lacking that nobody can figure out how to configure the thing except by following examples is the main problem that leads people to fear webpack configuration and to cargo cult magical config files that they are afraid to touch.
Mature tools can be understood in principle and configured without needing to see "how someone else did it."