Why does the configuration schema change so often?

[phoenixeliot-practicum]

This is a bit of a philosophical question I've had for a while with webpack. Why does the schema for the configuration file change so often between versions? The way I see this most is that old advice on StackOverflow is usually wrong, because some property will have changed name since it was posted, or the many different ways of specifying a single property have changed in backwards-incompatible ways (eg the many ways of specifying use, loader, loaders, etc).

This causes problems, especially for new users / ones not deeply familiar with webpack, in that most old examples about how to configure webpack don't work anymore — if you find two answers on StackOverflow that should combine to serve your needs, usually this won't work because they are answering for different versions of webpack, and probably both are out of date with the current version, and migrating them to the current syntax is very nonobvious (and some old default plugins may not even work anymore or be superseded by some new plugin).

This is the primary reason I find webpack so hard to work with when setting up something complex.

On the pragmatic end of this question: How can we mitigate this problem? Are there feasible ways to detect this kind of problem and report it in a way that users not very familiar with webpack can use to migrate parts of their configuration correctly?

[alexander-akait]

We are reducing number of these changes, most of them are soft deprecations (i.e. you get a warning in console but all will work fine), unfortunately some of them are hard deprecations (i.e. code was removed), it is very hard to support old approaches/logic/options with new stuff.

Could you specify what options specifically you are talking about?

[phoenixeliot-practicum]

Admittedly it's been a while since I first started thinking about this problem, so I'll have to remember specifics slowly.

The most recent example that made me think of this was that contentBase was changed to static, with new/different syntax, for I think the devServer config.

I know the many ways of configuring loaders (use, loader, loaders) has changed a lot in confusing ways over time, especially what shapes of values are valid for those properties, as there are a lot of "shorthand" ways of configuring those as well, so there's many shapes for just that part for each version of the config schema.

[phoenixeliot-practicum]

An example point of confusion:

• v4 docs lists the property as devServer.contentBase
• v5 docs say devServer.static
• but the migration guide for migrating to v4 (of webpack-dev-server, I notice now) implies that contentBase changed to static between v3-v4, not from v4-v5.

Maybe this is because the version numbers for webpack and webpack-dev-server don't match? But it took me writing out this whole message to have that thought, and I have no idea if it's right. Either way, it's confusing.

[phoenixeliot-practicum]

Plugins that are bundled with Webpack changing how you're meant to use them between minor versions of webpack is also a big source of confusion, since they affect how you have to write your webpack config as well.

I'm not sure exactly how the bundling works with pinning versions, or if they exist independently instead of being pinned together. I haven't checked on that in a while.

[sokra]

webpack-dev-server is not bundled with webpack. You have it separately in your package.json.

We are very careful to not introduce any breaking change in webpack during minor version, and afaik we never introduced a breaking change to the schema. What we did in the past was to make the schema a bit stricter to disallow some values that were allowed before but not intended and broken.

I'm pretty sure the same is true for webpack-dev-server, but independently from webpack as it's a separate dependency.

[alexander-akait]

@phoenixeliot-practicum Unfortunately webpack dev server has a lot of legacy code and wrong behavior, due this we done full refactor, if you have problems with migration you can open an issue and describe what is hard to understand and we will improve it