Hacker News Reader

Comment by codefined | Hacker News Reader

I'm not sure, my opinion of Webpack is completely different.

We used a ~20 line configuration file found on Gist to replace our ~400 line gulp build. It resulted in better optimisation, less hassle and "Just Worked™".

We wanted to add a few more things to our configuration, literally just took running `npm install some_package`, followed by requiring it in the webpack configuration.

View on HN

> a ~20 line configuration file found on Gist

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?)

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.

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.

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.

I’ve been able to do everything I want to with create-react-app which uses webpack internally, giving you a zero configuration experience.

With async import I am able to do code splitting. With react-intl-cra I can pull formatted messages out of my code. I had to add a grunt file to compile LESS into src, but it was easy to integrate with my package.json scripts.

The fact that you had to add grunt, the grandfather of webpack, speaks volumes. Why didn’t you just configure wp to compile less?

That has less to do with webpack and more to do with create-react-app which doesn't allow you to modify the webpack config. The gp didn't really need to use gulp, you can compile less with package.json scripts.

As mentioned, create-react-app doesnt let you configrue anything (ok, almost anything), and doesn't support LESS/Sass by design.

Though you usually don't even need that much. Just using the node-sass or less compilers directly usually work fine. Or use something like Glamor or Styled Components to punt on the problem altogether.

Using this should make WebPack work with LESS files. I'm no expert, but my understanding is that this says "for all files matching *.less, run them through the CSS and LESS loaders, then use the Extract Text Plugin" (which pulls things into their own file; you'll need to configure it in the plugins).

{test: /\.less$/i, use: ExtractTextPlugin.extract(['css-loader', 'less-loader'])}

Edit: forgot a brace.

Thanks! One thing - I'm not using WebPack directly and indeed, I have no access to the WebPack configuration because Create-React-App hides all of that from me.

I can eject the app from Create-React-App and get a normal WebPack project, but I won't do that unless it's absolutely necessary because the huge community of Create-React-App devs are taking care of my config for me.

create-react-app now uses some kind of extensible build scripts in form of react-scripts: webpack files which you can clone and modify and use without ejecting.

here's one for less: https://www.npmjs.com/package/create-react-scripts-less

also here are the official docs: https://github.com/facebookincubator/create-react-app/blob/m...

Any ambitious project is sooner or later going to have to delve into their tooling, and not depend on examples they found of things that work. I admit it's nice you found something that worked exactly as you wanted, and my experience is I can often find what I want exactly when I start but sooner or later you need to add to it. And then things start to get less pleasant.

Reply on news.ycombinator.com