4 ms·

I suspect that the Webpack team thinks that developers' favourite job is to upgrade tool configurations. I mean, it's great that improvements are being made, bu

I suspect that the Webpack team thinks that developers' favourite job is to upgrade tool configurations. I mean, it's great that improvements are being made, but breaking changes are not. Remember that the Webpack team has shown to be actively hostile to people who just want to keep their 2-year-old codebases work without doing needless upgrade work. They removed the webpack 1 docs [1], so if you have a few-years-old codebase that you want to get up and running, and somehow you get a webpack error, the message from Webpack is "screw you, upgrade to webpack 3 first and only then we'll allow you to read the docs". I have no reason to not expect the same to happen with Webpack 4, and the inevitable Webpack 5, 7 months from now. Webpack 2/3 docs will be subtly removed, retired and forgotten. We're all forced to keep doing work to make something work that already worked perfectly fine. Now, I'm well aware that an angry rant on the internet about the voluntary work from open source contributors is not particularly constructive. I've singled out the Webpack team here, but the reality is that a big part of the web dev ecosystem, across languages, does not care much about backward compatibility. I'd love for that attitude to change. In semver, every major version is a tragedy. [1] https://webpack.github.io/docs/using-plugins https://webpack.github.io/docs/using-plugins

deleted 9y ago
[deleted]
fenomas 9y ago
> but this does not even include a list of breaking changes. TFA: > For the full list of changes, features, and internal API modifications, please refer to our change log!!! Link: https://github.com/webpack/webpack/releases/tag/v4.0.0-beta.0 https://github.com/webpack/webpack/releases/tag/v4.0.0-beta....
- skrebbel 9y ago
  Oh damn, that was bad. Thanks, I edited my comment.
  - fenomas 9y ago
    Thanks! FWIW I think your other comments were plenty legitimate, and definitely don't deserve to be downvoted so low (below that inane "wtf emojis??" comment, of all things). Although with that said, I doubt webpack can do anything about what you're saying except to try to be conscientious. Obviously breaking too often is bad, but naturally that doesn't mean never ever breaking is necessarily preferable.
    - skrebbel 9y ago
      Thanks, appreciate that. I agree with the nuance you add, but also note that the last major version was released July 2017. This is not "never ever breaking", this is breaking all the time :-) There's plenty middle ground. A lot of the breaking changes could be solved by versioned config formats, for example. Maybe not all, but then maybe the remaining things that are now breaking would be worth keeping alive, albeit as a piece of legacy code that nobody wants to work on improving anymore. I don't know enough about webpack internals to go deep here, but I'm convinced that if there's a strong desire to stay backward compatible it's possible. The webpack team has no such desire, which is their prerogative but I'm still sad about it.
      - fenomas 9y ago
        I'm not sure you're being fair with that last bit. Granted, migrating webpack 1->2 was a nightmare even without the docs issue. But in contrast I moved from 2->3 without even touching my (fairly nontrivial) config and everything worked. Presumably there were breaking changes somewhere, but I got the impression they only really affected plugin authors. So I'm not sure it's fair to decide the devs don't care about breaking changes. It seems more reasonable to assume that some wrong choices were made early on (including about how to handle docs and major releases), and they've been learning and getting better since. After all, if like most things it started out as someone's weekend hack, with no thought of growing into the powerhouse it is now, some early stumbles are fair enough, right?
thelarkinn 9y ago
We strive to be as backwards compatible as possible. But we also hold ourselves accountable to keeping pace with the ecosystem. Most breaking changes are to accommodate the number one ask of our users: faster, smaller builds. We asked what the time frame they wanted for releases. We got out of a couple thousand responses 6mo being the sweet spot. Appreciate the candid feedback though. In regards to the v1 docs: we wanted to have a fresh start. I don't imagine our docs pages now changing for awhile. Each major breaking change we ship a migration guide so that people can upgrade.
- skrebbel 9y ago
  Sean, you don't know this but for quite a while now I've been amazed about your work responding to everybody complaining about Webpack on the internet, anywhere. There's absolutely no requirement for you to be so nice to users and yet, here you are again. Hats off, you're making the world a little bit prettier. This time I'm the one complaining, and I must admit that I'm curious about the exact wording of that question about release time frames. If you asked "how often do you want to make config changes just so you can update Webpack to the latest version", I bet many people would answer "never" instead of "6 months" :-) But hey, we established that we have different ideas about what the compat sweet spot is and you and yours are the one doing all the selfless work and I'm the guy complaining on the internet, so take everything I say with a bag of salt. All that said, any chance you could make a teeny tiny little link from the Webpack 1 "THESE DOCS ARE GONE" pages to http://devdocs.io/webpack~1/ http://devdocs.io/webpack~1/ or some place like that? There are people who inherit old codebases and it would be very nice for them to not _have_ to update Webpack just to find answers to their problems.
  - bsimpson 9y ago
    When I first started using Webpack 4 years ago, it had the most finnicky, difficult-to-configure (perhaps even magic) API I can think of. It worked really well once you got it configured, and wSokra was incredibly helpful and supportive in the chat room; but if you didn't have a known-working config and/or access to wSokra, well, good luck. I'm highly supportive to anything they can do to make it easier to configure and maintain, even if the cost is breaking the old APIs and making folks migrate to newer ones. Hopefully as someone works on a library and learns a problem space more thoroughly, they have better knowledge of what an ideal API would look like. I know migration can be painful, but I'm very supportive of long-run improvements to a project.
Sacho 9y ago
http://devdocs.io/webpack~1/ http://devdocs.io/webpack~1/
- skrebbel 9y ago
  Cool, thanks!
deleted 9y ago
[deleted]
arenaninja 9y ago
I'm currently upgrading a repo that is maintained internally and uses grunt+webpack+karma+jasmine and I strongly agree with this comment. The tool has been running webpack 1 and it works but now that webpack 1 docs have been removed we want to upgrade to webpack 2. It's been a host of issues, with the API changes being the least of it. webpack 2 introduced ES6 syntax in their plugins which grunt mangles when passed to its config https://github.com/gruntjs/grunt/issues/1595 https://github.com/gruntjs/grunt/issues/1595. Admittedly that's a grunt issue but seeing how many teams use this tool and have already configured their applications to build via Gruntfiles we can't move things overnight. I had issues with loaders (now rules) running at the appropriate time for istanbul as well and had to go through two or three now-defunct packages and piece together how to make it work with our rather unique setup. Honestly in this adventure I think our issue is grunt and the underlying bespoke hacks people have designed over the years, but in Enterprise this just keeps me from being out of a job.
aeriklawson 9y ago
I personally think you're overstating the amount of work required to upgrade between Webpack versions. You generally should not be ignoring your tech stack for 2+ years in the first place either - nobody likes spending time staying on top of updates, but that's the world of software. As for your complaint about backwards compatibility, I'd agree, but there's only so far you can go backwards before it comes pretty ridiculous to support ecosystems so far behind the curve.
leomdg 9y ago
Well, you wanted a capitalist world, didn't you? WebPack was forced to upgrade to a zero config tool because of Parcel's threat. They couldn't let the others take that place. Now there you have it, progress without end. Developers constantly upgrading, until death does them apart!

deleted 9y ago

[deleted]

fenomas 9y ago

> but this does not even include a list of breaking changes. TFA: > For the full list of changes, features, and internal API modifications, please refer to our change log!!! Link: https://github.com/webpack/webpack/releases/tag/v4.0.0-beta.0 https://github.com/webpack/webpack/releases/tag/v4.0.0-beta....

skrebbel 9y ago
Oh damn, that was bad. Thanks, I edited my comment.
- fenomas 9y ago
  Thanks! FWIW I think your other comments were plenty legitimate, and definitely don't deserve to be downvoted so low (below that inane "wtf emojis??" comment, of all things). Although with that said, I doubt webpack can do anything about what you're saying except to try to be conscientious. Obviously breaking too often is bad, but naturally that doesn't mean never ever breaking is necessarily preferable.
  - skrebbel 9y ago
    Thanks, appreciate that. I agree with the nuance you add, but also note that the last major version was released July 2017. This is not "never ever breaking", this is breaking all the time :-) There's plenty middle ground. A lot of the breaking changes could be solved by versioned config formats, for example. Maybe not all, but then maybe the remaining things that are now breaking would be worth keeping alive, albeit as a piece of legacy code that nobody wants to work on improving anymore. I don't know enough about webpack internals to go deep here, but I'm convinced that if there's a strong desire to stay backward compatible it's possible. The webpack team has no such desire, which is their prerogative but I'm still sad about it.
    - fenomas 9y ago
      I'm not sure you're being fair with that last bit. Granted, migrating webpack 1->2 was a nightmare even without the docs issue. But in contrast I moved from 2->3 without even touching my (fairly nontrivial) config and everything worked. Presumably there were breaking changes somewhere, but I got the impression they only really affected plugin authors. So I'm not sure it's fair to decide the devs don't care about breaking changes. It seems more reasonable to assume that some wrong choices were made early on (including about how to handle docs and major releases), and they've been learning and getting better since. After all, if like most things it started out as someone's weekend hack, with no thought of growing into the powerhouse it is now, some early stumbles are fair enough, right?

thelarkinn 9y ago

We strive to be as backwards compatible as possible. But we also hold ourselves accountable to keeping pace with the ecosystem. Most breaking changes are to accommodate the number one ask of our users: faster, smaller builds. We asked what the time frame they wanted for releases. We got out of a couple thousand responses 6mo being the sweet spot. Appreciate the candid feedback though. In regards to the v1 docs: we wanted to have a fresh start. I don't imagine our docs pages now changing for awhile. Each major breaking change we ship a migration guide so that people can upgrade.

skrebbel 9y ago
Sean, you don't know this but for quite a while now I've been amazed about your work responding to everybody complaining about Webpack on the internet, anywhere. There's absolutely no requirement for you to be so nice to users and yet, here you are again. Hats off, you're making the world a little bit prettier. This time I'm the one complaining, and I must admit that I'm curious about the exact wording of that question about release time frames. If you asked "how often do you want to make config changes just so you can update Webpack to the latest version", I bet many people would answer "never" instead of "6 months" :-) But hey, we established that we have different ideas about what the compat sweet spot is and you and yours are the one doing all the selfless work and I'm the guy complaining on the internet, so take everything I say with a bag of salt. All that said, any chance you could make a teeny tiny little link from the Webpack 1 "THESE DOCS ARE GONE" pages to http://devdocs.io/webpack~1/ http://devdocs.io/webpack~1/ or some place like that? There are people who inherit old codebases and it would be very nice for them to not _have_ to update Webpack just to find answers to their problems.
- bsimpson 9y ago
  When I first started using Webpack 4 years ago, it had the most finnicky, difficult-to-configure (perhaps even magic) API I can think of. It worked really well once you got it configured, and wSokra was incredibly helpful and supportive in the chat room; but if you didn't have a known-working config and/or access to wSokra, well, good luck. I'm highly supportive to anything they can do to make it easier to configure and maintain, even if the cost is breaking the old APIs and making folks migrate to newer ones. Hopefully as someone works on a library and learns a problem space more thoroughly, they have better knowledge of what an ideal API would look like. I know migration can be painful, but I'm very supportive of long-run improvements to a project.

Sacho 9y ago

http://devdocs.io/webpack~1/ http://devdocs.io/webpack~1/

skrebbel 9y ago
Cool, thanks!

deleted 9y ago

[deleted]

arenaninja 9y ago

I'm currently upgrading a repo that is maintained internally and uses grunt+webpack+karma+jasmine and I strongly agree with this comment. The tool has been running webpack 1 and it works but now that webpack 1 docs have been removed we want to upgrade to webpack 2. It's been a host of issues, with the API changes being the least of it. webpack 2 introduced ES6 syntax in their plugins which grunt mangles when passed to its config https://github.com/gruntjs/grunt/issues/1595 https://github.com/gruntjs/grunt/issues/1595. Admittedly that's a grunt issue but seeing how many teams use this tool and have already configured their applications to build via Gruntfiles we can't move things overnight. I had issues with loaders (now rules) running at the appropriate time for istanbul as well and had to go through two or three now-defunct packages and piece together how to make it work with our rather unique setup. Honestly in this adventure I think our issue is grunt and the underlying bespoke hacks people have designed over the years, but in Enterprise this just keeps me from being out of a job.

aeriklawson 9y ago

I personally think you're overstating the amount of work required to upgrade between Webpack versions. You generally should not be ignoring your tech stack for 2+ years in the first place either - nobody likes spending time staying on top of updates, but that's the world of software. As for your complaint about backwards compatibility, I'd agree, but there's only so far you can go backwards before it comes pretty ridiculous to support ecosystems so far behind the curve.

leomdg 9y ago

Well, you wanted a capitalist world, didn't you? WebPack was forced to upgrade to a zero config tool because of Parcel's threat. They couldn't let the others take that place. Now there you have it, progress without end. Developers constantly upgrading, until death does them apart!