Hacker News Reader

Comment by manigandham | Hacker News Reader

Webpack is not hard, the config is a simple javascript app that has to return an object following a specific schema. It's a list of entries (the starting file of an app) and the loaders to use for each type of file, based on a regex test of the filename.

It is maybe 0.05% of the difficulty of any actual app. Why is it so confusing when you can clearly create real apps without a problem?

View on HN

> Webpack is not hard, the config is a simple javascript app that has to return an object following a specific schema

There's so many variations in what stacks people are using and what build steps are required for different projects that setup issues and bugs to workaround are virtually inevitable.

I want to move up to the next major version of Webpack for one project for example but after spending a total of several days getting my builds working correctly already, I'm almost certain it'll eat up at least a few days to get everything working again (e.g. production and development builds, source maps, live reloads, hot reloading, template compilation, TypeScript compilation, SASS compilation, project paths, optimizations).

Saying it's just simple JavaScript is completely overlooking all the plugins and configuration you have to stitch together and when things go wrong it can be challenging to know what to Google for.

I understand, but that's more of an issue of there being so many external plugins. The entirety of webpack itself is just a small core runner with plugins and they're slowly moving more functionality into the main package.

Fundamentally I think the issue just comes down to terrible documentation and the spread of outdated blogs and examples as a result. The team seems to know that and they're working on it but it should be the highest priority for them.

Honestly though, starting from scratch, you can build a complex config (with all those things you mentioned) in about 30 minutes. If you really need help then post it here or on stackoverflow and you'll get an answer pretty quick.

> Honestly though, starting from scratch, you can build a complex config (with all those things you mentioned) in about 30 minutes.

If you're sticking to a pre-built template or simple defaults maybe but once you start to customise things it's easy to get stuck in your own unique problems. Resolving path issues can easily eat up 30 minutes alone so I'd say you're severely underestimating.

> If you really need help then post it here or on stackoverflow and you'll get an answer pretty quick.

Once you've got your own unique combination of plugins going, it gets difficult to know where the problem is and you're less likely to get help if you've got something bigger than a minimal example. I know how to ask for help but there's just something about build system which makes it more challenging and more frustrating to get help compared e.g. typical programming problems.

I'm not sure why paths are such a big issue. The config object only needs the path to your applications entry file, and the path to where to put the output. All the paths within your app js (the import() statements) dont have anything to do with webpack and wouldn't run anyway if they were wrong.

What other paths are you running into problems with? Also debugging this is just like any other app, start with 1 line at a time and see what changes. You can technically run it all inside of a debugger but that's a lot of setup so the old-school 1 change at a time + console.log() statements work well. Remember its just a single-file js app that produces an object.

The issue is that for the result there are too many variables and unknowns that complicate the most important thing. Writing the app and not taming the build process. Take Ember for example. It lacks the freedom to configure as you please but gets you going creating very fast.

It is with the paths in your styling (images, fonts) which by default are checked and rewritten during compilation (which fails if he can't find the files).

I feel your pain. Tried moving away from bower + simple gulp concat to pure NPM and webpack on an old angular 1.x app. Ouch.

Webpack as of now reserved to just vendor. Porting the whole app over will take a significant amount of work. I don't have that at the moment, not with 2 or 3 deadlines on my plate!

The webpack "schema" is extremely complex and dynamic in shape. You can often return a scalar, or an Array, or some objects with various optional keys for the same config option. That choice has a cognitive price and documentation fails to document all this in a sane maner.

Also, even the most popular webpack plugins have trouble tracking the latest version of webpack and you often still have blocker bugs months after a release, so you often have to try many, many combinations before your workflow does what you want.

Right, so it's not difficult but just annoyingly undocumented and unfinished. I've already stated that it's the biggest issue with the project and something they should resolve before making even a minor update, but the lack of any project managers makes that unlikely.

Webpack allows writing the config in typescript so you at least have static analysis on the correctness of the config object you generate.

It’s a huge pain when a new version of webpack is released and most existing guides become outdated.

Yes, documentation is the single biggest problem for the webpack team and something they seriously screwed up with the release of webpack 4. I think they understand now but it remains to be seen. Unfortunately they have lots of devs but no clear project manager, which is what really makes larger projects work well.

The step from 2 to 3 wasn‘t great too though.

It is by far the least intuitive configuration I ever regularly encounter.

That's because it's not a config file, it's a javascript app that is run to produce a javascript object, which is then used as the config.

That object needs 4 main properties: the entry (the file where your app begins), the output (where to put the compiled stuff), the loaders (what to use to load various file types identified by a regex to test the file name), and plugins (for anything else that operates on the compiled output).

Gulp was JavaScript as well, and much simpler to understand!

Reply on news.ycombinator.com