8 ms·

An attempt to upgrade to Webpack 4

130 points by isuckatcoding 9y ago

alexdong 9y ago
I keep telling myself: "embrace changes. an upgrade is great; new defaults are cool; performance improvements are great; just do it; just do it". Yeah. One day. PS. I do miss the days when you can just read a book and `man` your way around the dev environment.
- monaghanboy 9y ago
  I think your ideal exists in backend/SRE roles.
jacquesc 9y ago
Haha, pretty much my life every 3 months. Welcome to the new world of frontend development. Luckily the bad also comes with the good. Adding and upgrading components off npm in a webpack project is almost always a breeze.
- 6t6t6t6 9y ago
  Another option is to wait just a couple of months to upgrade, so you give time to the library developers to put their s* together, fix bugs, and write some documentation. At the end, from all the features your users could care about, your webpack version is not one of them.
  - jacquesc 9y ago
    I'm not actually complaining, I'm happy the webpack team is making improvements so fast. The reason I upgrade so often is they actually make meaningful fixes. Bugs that I find tend to be in github issues as closed and available in the current release. Hence the pain of upgrading.
  - slig 9y ago
    > Another option is to wait just a couple of months to upgrade I did that when webpack 3 was released and now I'm two versions behind.
knackers 9y ago
Went through this exact process last week. Did they really need to remove CommonsChunkPlugin? Feels like breaking stuff for a slightly nicer API. If this were React we would've had a deprecation warning for a few versions.
- shakna 9y ago
  > If this were React we would've had a deprecation warning for a few versions. If this were React, you would have got docs with a release. Choosing to release before documentation is done, for a tool developers are supposed to use as a black box, which has a lot of strange configuration that is required, is a really strange choice for something with so many breaking changes.
  - Zalastax 9y ago
    They haven't released webpack 4 yet.
    - Klathmon 9y ago
      Yes they have, webpack 4.1.1 is the current version.
    - shakna 9y ago
      They have [0][1] ("beta" was dropped from the v4 releases at v4.0.0), and are actually in the process of updating the documentation [2]. It's just odd to do that after a release. [0] https://www.npmjs.com/package/webpack https://www.npmjs.com/package/webpack [1] https://github.com/webpack/webpack/releases https://github.com/webpack/webpack/releases [2] https://github.com/webpack/webpack.js.org/pull/1905 https://github.com/webpack/webpack.js.org/pull/1905
      - Zalastax 9y ago
        Whoops, guess it's a good idea to check things before blurting something out. In that case I'm not sure what's best, to let newcomers in on the new goodies of v4 or to avoid confusing previous users.
ericmcer 9y ago
Is it weird that I miss gulp and even grunt sometimes? Webpack does some really cool stuff with basic configuration, but gives me a scary black box feeling, like if it really wanted to it could stop working and I would be unable to fix it. I never got the same feeling with gulp/grunt, maybe the bulky config files give a sense of control.
- unclebucknasty 9y ago
  >gives me a scary black box feeling, like if it really wanted to it could stop working and I would be unable to fix it This was verbatim my thinking when evaluating Vue 2 a while back. Its reliance on Webpack or Browserify for optimal use really gave me pause. I could just see myself losing days trying to figure out which bit got flipped to stop its working. Vue 2 was new at the time as well, so I wasn't sure about adoption, ecosystem, and/or the maintainers' committment. Looking back, I would've rolled the dice. But, all of this to say glad I'm not alone in that black boxes give me pause in a world where everyone seems to rush headlong into the next big thing, ceding ever more control.
  - CharlesW 9y ago
    > Its reliance on Webpack or Browserify for optimal use really gave me pause. Mind elaborating on what you mean by "for optimal use"? For example, I use Brunch with Vue 2 and it seems to work fine.
    - LukeShu 9y ago
      There is no complete stand-alone Vue SFC compiler; every SFC compiler is written as a plugin for a specific bundler. The 3 official implementations are the Webpack, Browserify, and Rollup plugins. There's no significant code-sharing between them (and I'm sure there are no subtle differences that will bite you), and the Browserify and Rollup plugins can lag months behind the Webpack one--they still don't support functional SFCs, which were added in Vue 2.5.0 back in October. So, how does vue-brunch work? It declares the Browserify plugin as a dependency, and wraps it.
btown 9y ago
IMO, Webpack (and React Router [0]) have been in this weird and honestly toxic place, where there was very little regard held for backwards compatibility and gradual deprecation by the core teams at first, so businesses with larger apps became marooned on previous versions as soon as the first major version change... thereby not contributing their expertise and bug reports (they spent that time fighting against the lack of documentation), and thereby making it even more difficult for the core teams to get feedback on people's real-world migration woes. It's fair to say that there were problems in the earlier APIs, but if that's the case, make changes gradually, even create an RFP process, tease/market your API change proposals to get feedback from people who might say "this is not something we can adopt easily, but you could add this param for backwards compatibility." It'll take longer to get to an API that feels "perfect," but it makes for a stronger culture. [0] https://github.com/ReactTraining/react-router/blob/master/packages/react-router/docs/guides/migrating.md https://github.com/ReactTraining/react-router/blob/master/pa...
- bfred_it 9y ago
  I remember reading of Babel maintainers releasing betas and asking for feedback but not many helped; most just came to complain after the release. Webpack 4 has been in beta for a while but not enough people tested it on real projects, evidently.
  - vanderZwan 9y ago
    Well, when there isn't enough documentation, yet so many breaking changes are introduced, then I don't really see how exactly people should have managed to get it to work to test it on real projects.
    - bfred_it 9y ago
      You're not wrong; documentation especially for migrating is poor. Having to google one error at a time is annoying.
    - btown 9y ago
      Yep - either introduce redesigned APIs with deprecation warnings in minor releases, or at least build codemods. Make it so that if you fix everything deprecated, you can upgrade with minimal effort. React itself does this, for instance.
mratzloff 9y ago
OK, so faster builds—and what else? Why not wait until documentation catches up and spare yourself the trouble?
- jazoom 9y ago
  I'm curious. How will we know when documentation has caught up?
  - kaoD 9y ago
    Webpack 5 will be released.
- enzanki_ars 9y ago
  By now, the documentation should have been updated in my mind as they are on version 4.1.1 (https://github.com/webpack/webpack/releases/latest https://github.com/webpack/webpack/releases/latest).
- GabeRicard 9y ago
  Because I was just trying it out? Are you saying it's wrong to test a beta and provide feedback to the authors?
  - mratzloff 9y ago
    Sure, that's perfectly fine. I interpreted your original post as a public warning or complaint to other users. You've updated the Gist since then with a big disclaimer, so perhaps I wasn't the only one. More broadly, I often see developers stay on the cutting edge when they don't have a security or feature need to, then complain about it.
Zalastax 9y ago
I know that this is tongue in cheek , but shouldn't we give the maintainers time to solve the documentation before we start complaining too much? The changes they are making seems to make sense to me. They are adopting patterns that the community uses and provide solutions to hacks that have emerged from real needs. Webpack was in my opinion already simple, and it's getting simpler every release. I can't imagine the horrible mess I would have if I went back to gulp.
- krankthat 9y ago
  Just like git tags, release notes, makefiles, etc ... Documentation is one of those things that needs to be updated as part of a new release.
  - Zalastax 9y ago
    Yes, it could have been handled better. I guess you need to consider whether it's best to let newcomers in on the v4 goodness or to avoid aliating users of v3. The pragmatic approach is to at least mention somewhere that v3 users should wait on upgrading.
lmcardle 9y ago
As someone who has worked with many of the various tools out there, I have a lot of respect for the way the EmberJS team handles upgrades. I personally wish more teams learned from their success. Their mantra is “stability without stagnation.” While it is not perfect, the team appears to try hard to move the framework forward without breaking backwards compatibility. When it comes to a major release, I.e. the just released 3.0, the team released no new features, but rather just removed the features that had been depreciated in earlier releases. Like or hate Ember as a framework, the team has developed some very good release processes and practices a lot of us could learn from.
andrew_ 9y ago
Hello. Webpack team member here. The webpack@4 release was, well, interesting. I can't add much that hasn't already been said - but I can say that we're working to make sure there will never be another webpack release that suffers from the same kind of documentation shortcomings. There's a metric poopton of good stuff in the release, and we're still working to get all of it written down. That said, look for future major releases to be far more proactive than reactive with regard to documentation, announcements, and migration details.
- ggregoire 9y ago
  Hey Andrew, thanks for the great work on v4. Webpack is one of these tools I can't imagine working without.
- tbrock 9y ago
  Hey thanks for all the hard work! > I can say that we're working to make sure there will never be another webpack release that suffers from the same kind of documentation shortcoming We still have time to make sure this release has good docs. Please don’t give up on it just yet! Can we make some task issues on github that ask people to document a portion of the code/process?
  - shakna 9y ago
    Have a look at this issue [0], I think it covers most of the docs for v4. [0] https://github.com/webpack/webpack.js.org/issues/1861 https://github.com/webpack/webpack.js.org/issues/1861
- chvid 9y ago
  I upgraded my projects to webpack 4 about a month back and I did not have much of an issue. The builds are definately faster. I would say this though: Webpack (and in general the current JavaScript-way of building) is one of those build systems that invite programmers to put a lot of stuff into their project builds plus a lot of programmers rely on templates or generators that gives a lot of code that they never bother to understand. That is a recipe for stuff that is hard to upgrade and hard to maintain.
blueside 9y ago
I've used Webpack on and off since v2 and I'm still no fan. If I'm being honest, there's been times that it's perhaps been the worst dev experience I've endured in the last decade. Can we use Parcel as a replacement yet?
- thelarkinn 9y ago
  Sure, but since your experience is not configuring anything, how are you going to know what it's actually doing to your code. And what are the tradeoffs? Seems like many don't have this answer because they don't have good archetectural reasons for choosing it.
  - BigJono 9y ago
    For what it's worth, my experience with Parcel so far has been a show stopping bug that makes CSS Modules unusable with it, was quite difficult to diagnose (as with any bug in a dependency, I spent yonks looking at my own codebase), and has so far gone un-fixed. https://github.com/parcel-bundler/parcel/issues/378 https://github.com/parcel-bundler/parcel/issues/378 I don't see how this is really possible given the relatively high usage level of CSS Modules, but whatever. I'm forced to stick with Webpack for the time being.
- conradfr 9y ago
  There is side projects that I literally don't start because I don't want to deal with Webpack and Babel (I don't think I have ever had a project where Babel wasn't complaining it was out of date even on greenfield install). Another complaint for me is how all tutorials, boilerplates etc mingle nodejs server and react/angulas/vue deps and code where all I want is frontend code and build and I have to remove things by trial and error.
monaghanboy 9y ago
Another major version was again released? Seems like literally just a few months ago when, just after upgrading my team's codebase to Webpack 2, Webpack 3 came out. Why do front-end application frameworks (e.g. Angular, and even React) and build tools constantly feel the need to reinvent what they just reinvented? Don't people (users and developers alike) recognize and tire of the churn? Stepping back though, a thread like this appears on HN at least once every few months, so I guess this is just par for the course.
- darepublic 9y ago
  I am staying with webpack ~2 for now, it does everything I need it to do
- franciscop 9y ago
  Because they learn from mistakes and can make it better the next time! That happens everywhere; except JS world (at least with npm) is very, very new (relatively speaking). Also now there are many more devs than when the older languages came out, so the experimentation is a lot wider.
  - nl 9y ago
    I'm not convinced that this is true. In the JS world different layers feel very closely bound and it isn't usually clear at all how to leave out things which are (mostly at some level) optimisations. That isn't great when things go wrong.
  - vanderZwan 9y ago
    > Because they learn from mistakes and can make it better the next time! Well, except seemingly learning from the mistakes made when introducing breaking changes. I not being a cynical jerk bashing on WebPack in particular here. I use it every day and am grateful for its existance, and look forward to the point where migrating to version 4 is going to be relatively painless, at which point I'll actually give that another try. But on the whole, it's like nobody in the JS world seems to learn from the mistakes of other JS projects and they have to make them again themselves.
stevebmark 9y ago
According to Webpack's donation site, https://opencollective.com/webpack https://opencollective.com/webpack, the creator of Webpack, "Sokra," made $44,164 off of Webpack development in 2017 (and $9,000 so far in 2018). We're in a new world of sustainable open source software development, enabled by services like Patreon and this one. Maybe it's petty, but as someone who works on several open source projects without reimbursement, I hope that such "hefty" funding leads to better documentation, better community support, and cleaner upgrade paths. Webpack is notoriously fickle and confusing when it comes to configuration, and at a glance Webpack 4 doesn't seem to have helped with that. Although I certainly appreciate performance improvements. Can I request that funds be diverted into community support and enforcing clean writing across documentation pages? That's what Webpack needs most, and has always needed, by far over any core API changes.
- dguo 9y ago
  You can vote on prioritization here: https://webpack.js.org/vote/ https://webpack.js.org/vote/
- sho 9y ago
  > the creator of Webpack, "Sokra," made $44,164 off of Webpack development in 2017 While I certainly welcome this new trend I wouldn't exactly call sub-45k "hefty". That's far below what the author could presumably make working for one of the big shops, and doesn't exactly leave much to "divert" if the author has any plans to pay rent, buy food, etc. As stated it's a great and promising trend, but I wouldn't be too hasty in calling for the author to start redistributing a fairly minimal income. That's barely enough for one person, let alone "staff".
thelarkinn 9y ago
PS: I submitted this response also in Reddit for those who come across it twice. It's not meant to be disingenuous (as I'll likely respond to individual comments also), just meant to show what our statement is. Hi all, We appreciate the feedback. So whether you care to know or not I'll explain where we stand as a project for our docs. So in this major release we want to try different ways to impact as many users as possible. So this time we consiously put priority on working directly with framework and tooling authors like angular, react, preact, vue to ensure they were unblocked on implementing v4. With this we decided: since plugins and loaders will also need time, we will give them a month and release our final version without breaking changes from RC. However I as a maintainer orchestrating all of our separate ecosystem, docs, and teams didn't realise we had been behind on contributions and work from our docs and when the 30 day window elapsed v4 shipped as promise. To not hold back v4 with docs is an organizational and communication error on my part and maybe even a side-effect of juggling my full-time job at Microsoft and the 120-140 hours I spend a month on webpack. I'm more then willing to own this, and for anyone frustrated, its on me and I'm sorry. However we grow and improve after any mistakes we make. So, we have some takeaways that we will build on for our next Major Release. A complete migration guide will be a primary shipping dependency for any future Major version of webpack going here forward. We learned that instead of focusing on frameworks as heavily to provide impact and upgrade paths, (which not have all done this yet), that instead focusing on content accessible to everyone is a far more impactful result. For now, we have the PR pending for our docs upgrade and I'll likely spend the majority of my free time ensuring we have it ready to release as soon as possible. Thank you all for being reasonable and patient with this. Major version releases like webpack 4 are much less likely to happen. This major release included the rewrite in our plugin system, which is the cause of incompatible loaders and plugins. We have no plans to rewrite it again as it is exactly where we need it to be in terms of performance, capabilities, etc. Therefore, look to most future Major versions to be less severe and impactful to loaders and plugins. I plan to spend much more focus on ensuring all of our separate teams are communicating for releases by coordinating all hands ship meetings. This ensures that we are on the same page and everyone is aware what each team has a dependency on. We actually only do have one full time engineer. And have attempted to fully fund a documentation team to work on it full time! It takes a considerable amount of effort to do right. And so thanks for understanding while we continue to work on it. Contributions are always welcome along with constructive feedback. Regardless, we appreciate as always support the positive comments we've seen here but also the actionable criticisms. It probably sounds redundant but we really stress the high bar and expectations that are set for us in the ecosystem as so many of you rely on webpack to ship your products and solutions to the web. We will keep on improving as we have since 2012 and hope you all continue to help us along the way. Sean + webpack Team (@TheLarkInn)
isuckatcoding 9y ago
So I found this gist as I was googling for my webpack error. Originally was trying to get the uglify plugin to work. Then I said screw uglify and STILL couldn't get it work. I gave up and ended up using Rollbar.
pacifika 9y ago
Stop guessing start learning. It sounds like the person doesn’t understand what each configuration command does.
- GabeRicard 9y ago
  I'm the author of the gist. You're exactly right. This was me guessing when I didn't understand the configuration options, because this was my attempt at learning the BETA of webpack 4 without the new docs available.
simon04 9y ago
There's a big webpack 4 documentation update PR in the pipeline: https://github.com/webpack/webpack.js.org/pull/1856 https://github.com/webpack/webpack.js.org/pull/1856
mnm1 9y ago
Angular, brunch, babel, webpack. While not limited exclusively to the JS community, it seems that much of the JS community especially does not care about backwards compatibility or long term support. Piling on new features and re-architecting everything with every major version number, and sometimes even with minor version numbers, seems to have taken over actually creating and maintaining useful products to the detriment of all software that uses such products. Now we end up with software that's dependent on literally un-upgradable components that are no longer supported and in some cases do not even get security patches. With certain breakages, the software cannot be built at all. Perhaps it might not be a bad idea for open source developers to include a small section in their documentation that details their intended philosophy for the future of the software. That way, people don't get duped into using software written by teams that plan to abandon it completely (I'm looking at Angular here) or partially (everything else).
GabeRicard 9y ago
Author of the gist here. Please don't take this as me complaining about webpack 4 in any way. This was me detailing my process of migrating to the webpack 4 BETA in order to provide feedback to the webpack team, and potentially help anyone else out who got stuck on a few things like I did. They're updating the documentation. Webpack is awesome and v4 is a great update and I highly recommend people try it out.
- disgruntledphd2 9y ago
  I think that this style of blog/info dump is really, really useful and speaks to how I have spent many, many weekends. Even though I don't really use much JS, I still got a real kick out of reading this.
  - GabeRicard 9y ago
    Haha. Thanks! I am trying to do this more, just for personal notes about projects. It makes it easier to go back later and remember what the pitfalls were.
Vinnl 9y ago
The upgrade seemed relatively straightforward with the release blog post. Really, it's the fact that many plug-ins will have to be updated that is holding the upgrade back, but that's not that much of a problem: I've simply documented the status of each [0], am following the respective issues/preparing to submit PRs myself if needed, and am meanwhile remaining on v3. [0] https://gitlab.com/Flockademic/Flockademic/issues/306#note_60571871 https://gitlab.com/Flockademic/Flockademic/issues/306#note_6...

130 points by isuckatcoding 9y ago

I keep telling myself: "embrace changes. an upgrade is great; new defaults are cool; performance improvements are great; just do it; just do it". Yeah. One day. PS. I do miss the days when you can just read a book and `man` your way around the dev environment.

monaghanboy 9y ago
I think your ideal exists in backend/SRE roles.

jacquesc 9y ago

Haha, pretty much my life every 3 months. Welcome to the new world of frontend development. Luckily the bad also comes with the good. Adding and upgrading components off npm in a webpack project is almost always a breeze.

6t6t6t6 9y ago
Another option is to wait just a couple of months to upgrade, so you give time to the library developers to put their s* together, fix bugs, and write some documentation. At the end, from all the features your users could care about, your webpack version is not one of them.
- jacquesc 9y ago
  I'm not actually complaining, I'm happy the webpack team is making improvements so fast. The reason I upgrade so often is they actually make meaningful fixes. Bugs that I find tend to be in github issues as closed and available in the current release. Hence the pain of upgrading.
- slig 9y ago
  > Another option is to wait just a couple of months to upgrade I did that when webpack 3 was released and now I'm two versions behind.

knackers 9y ago

Went through this exact process last week. Did they really need to remove CommonsChunkPlugin? Feels like breaking stuff for a slightly nicer API. If this were React we would've had a deprecation warning for a few versions.

shakna 9y ago
> If this were React we would've had a deprecation warning for a few versions. If this were React, you would have got docs with a release. Choosing to release before documentation is done, for a tool developers are supposed to use as a black box, which has a lot of strange configuration that is required, is a really strange choice for something with so many breaking changes.
- Zalastax 9y ago
  They haven't released webpack 4 yet.
  - Klathmon 9y ago
    Yes they have, webpack 4.1.1 is the current version.
  - shakna 9y ago
    They have [0][1] ("beta" was dropped from the v4 releases at v4.0.0), and are actually in the process of updating the documentation [2]. It's just odd to do that after a release. [0] https://www.npmjs.com/package/webpack https://www.npmjs.com/package/webpack [1] https://github.com/webpack/webpack/releases https://github.com/webpack/webpack/releases [2] https://github.com/webpack/webpack.js.org/pull/1905 https://github.com/webpack/webpack.js.org/pull/1905
    - Zalastax 9y ago
      Whoops, guess it's a good idea to check things before blurting something out. In that case I'm not sure what's best, to let newcomers in on the new goodies of v4 or to avoid confusing previous users.

ericmcer 9y ago

Is it weird that I miss gulp and even grunt sometimes? Webpack does some really cool stuff with basic configuration, but gives me a scary black box feeling, like if it really wanted to it could stop working and I would be unable to fix it. I never got the same feeling with gulp/grunt, maybe the bulky config files give a sense of control.

unclebucknasty 9y ago
>gives me a scary black box feeling, like if it really wanted to it could stop working and I would be unable to fix it This was verbatim my thinking when evaluating Vue 2 a while back. Its reliance on Webpack or Browserify for optimal use really gave me pause. I could just see myself losing days trying to figure out which bit got flipped to stop its working. Vue 2 was new at the time as well, so I wasn't sure about adoption, ecosystem, and/or the maintainers' committment. Looking back, I would've rolled the dice. But, all of this to say glad I'm not alone in that black boxes give me pause in a world where everyone seems to rush headlong into the next big thing, ceding ever more control.
- CharlesW 9y ago
  > Its reliance on Webpack or Browserify for optimal use really gave me pause. Mind elaborating on what you mean by "for optimal use"? For example, I use Brunch with Vue 2 and it seems to work fine.
  - LukeShu 9y ago
    There is no complete stand-alone Vue SFC compiler; every SFC compiler is written as a plugin for a specific bundler. The 3 official implementations are the Webpack, Browserify, and Rollup plugins. There's no significant code-sharing between them (and I'm sure there are no subtle differences that will bite you), and the Browserify and Rollup plugins can lag months behind the Webpack one--they still don't support functional SFCs, which were added in Vue 2.5.0 back in October. So, how does vue-brunch work? It declares the Browserify plugin as a dependency, and wraps it.

btown 9y ago

IMO, Webpack (and React Router [0]) have been in this weird and honestly toxic place, where there was very little regard held for backwards compatibility and gradual deprecation by the core teams at first, so businesses with larger apps became marooned on previous versions as soon as the first major version change... thereby not contributing their expertise and bug reports (they spent that time fighting against the lack of documentation), and thereby making it even more difficult for the core teams to get feedback on people's real-world migration woes. It's fair to say that there were problems in the earlier APIs, but if that's the case, make changes gradually, even create an RFP process, tease/market your API change proposals to get feedback from people who might say "this is not something we can adopt easily, but you could add this param for backwards compatibility." It'll take longer to get to an API that feels "perfect," but it makes for a stronger culture. [0] https://github.com/ReactTraining/react-router/blob/master/packages/react-router/docs/guides/migrating.md https://github.com/ReactTraining/react-router/blob/master/pa...

bfred_it 9y ago
I remember reading of Babel maintainers releasing betas and asking for feedback but not many helped; most just came to complain after the release. Webpack 4 has been in beta for a while but not enough people tested it on real projects, evidently.
- vanderZwan 9y ago
  Well, when there isn't enough documentation, yet so many breaking changes are introduced, then I don't really see how exactly people should have managed to get it to work to test it on real projects.
  - bfred_it 9y ago
    You're not wrong; documentation especially for migrating is poor. Having to google one error at a time is annoying.
  - btown 9y ago
    Yep - either introduce redesigned APIs with deprecation warnings in minor releases, or at least build codemods. Make it so that if you fix everything deprecated, you can upgrade with minimal effort. React itself does this, for instance.

mratzloff 9y ago

OK, so faster builds—and what else? Why not wait until documentation catches up and spare yourself the trouble?

jazoom 9y ago
I'm curious. How will we know when documentation has caught up?
- kaoD 9y ago
  Webpack 5 will be released.
enzanki_ars 9y ago
By now, the documentation should have been updated in my mind as they are on version 4.1.1 (https://github.com/webpack/webpack/releases/latest https://github.com/webpack/webpack/releases/latest).
GabeRicard 9y ago
Because I was just trying it out? Are you saying it's wrong to test a beta and provide feedback to the authors?
- mratzloff 9y ago
  Sure, that's perfectly fine. I interpreted your original post as a public warning or complaint to other users. You've updated the Gist since then with a big disclaimer, so perhaps I wasn't the only one. More broadly, I often see developers stay on the cutting edge when they don't have a security or feature need to, then complain about it.

Zalastax 9y ago

I know that this is tongue in cheek , but shouldn't we give the maintainers time to solve the documentation before we start complaining too much? The changes they are making seems to make sense to me. They are adopting patterns that the community uses and provide solutions to hacks that have emerged from real needs. Webpack was in my opinion already simple, and it's getting simpler every release. I can't imagine the horrible mess I would have if I went back to gulp.

krankthat 9y ago
Just like git tags, release notes, makefiles, etc ... Documentation is one of those things that needs to be updated as part of a new release.
- Zalastax 9y ago
  Yes, it could have been handled better. I guess you need to consider whether it's best to let newcomers in on the v4 goodness or to avoid aliating users of v3. The pragmatic approach is to at least mention somewhere that v3 users should wait on upgrading.

lmcardle 9y ago

As someone who has worked with many of the various tools out there, I have a lot of respect for the way the EmberJS team handles upgrades. I personally wish more teams learned from their success. Their mantra is “stability without stagnation.” While it is not perfect, the team appears to try hard to move the framework forward without breaking backwards compatibility. When it comes to a major release, I.e. the just released 3.0, the team released no new features, but rather just removed the features that had been depreciated in earlier releases. Like or hate Ember as a framework, the team has developed some very good release processes and practices a lot of us could learn from.

andrew_ 9y ago

Hello. Webpack team member here. The webpack@4 release was, well, interesting. I can't add much that hasn't already been said - but I can say that we're working to make sure there will never be another webpack release that suffers from the same kind of documentation shortcomings. There's a metric poopton of good stuff in the release, and we're still working to get all of it written down. That said, look for future major releases to be far more proactive than reactive with regard to documentation, announcements, and migration details.

ggregoire 9y ago
Hey Andrew, thanks for the great work on v4. Webpack is one of these tools I can't imagine working without.
tbrock 9y ago
Hey thanks for all the hard work! > I can say that we're working to make sure there will never be another webpack release that suffers from the same kind of documentation shortcoming We still have time to make sure this release has good docs. Please don’t give up on it just yet! Can we make some task issues on github that ask people to document a portion of the code/process?
- shakna 9y ago
  Have a look at this issue [0], I think it covers most of the docs for v4. [0] https://github.com/webpack/webpack.js.org/issues/1861 https://github.com/webpack/webpack.js.org/issues/1861
chvid 9y ago
I upgraded my projects to webpack 4 about a month back and I did not have much of an issue. The builds are definately faster. I would say this though: Webpack (and in general the current JavaScript-way of building) is one of those build systems that invite programmers to put a lot of stuff into their project builds plus a lot of programmers rely on templates or generators that gives a lot of code that they never bother to understand. That is a recipe for stuff that is hard to upgrade and hard to maintain.

blueside 9y ago

I've used Webpack on and off since v2 and I'm still no fan. If I'm being honest, there's been times that it's perhaps been the worst dev experience I've endured in the last decade. Can we use Parcel as a replacement yet?

thelarkinn 9y ago
Sure, but since your experience is not configuring anything, how are you going to know what it's actually doing to your code. And what are the tradeoffs? Seems like many don't have this answer because they don't have good archetectural reasons for choosing it.
- BigJono 9y ago
  For what it's worth, my experience with Parcel so far has been a show stopping bug that makes CSS Modules unusable with it, was quite difficult to diagnose (as with any bug in a dependency, I spent yonks looking at my own codebase), and has so far gone un-fixed. https://github.com/parcel-bundler/parcel/issues/378 https://github.com/parcel-bundler/parcel/issues/378 I don't see how this is really possible given the relatively high usage level of CSS Modules, but whatever. I'm forced to stick with Webpack for the time being.
conradfr 9y ago
There is side projects that I literally don't start because I don't want to deal with Webpack and Babel (I don't think I have ever had a project where Babel wasn't complaining it was out of date even on greenfield install). Another complaint for me is how all tutorials, boilerplates etc mingle nodejs server and react/angulas/vue deps and code where all I want is frontend code and build and I have to remove things by trial and error.

monaghanboy 9y ago

Another major version was again released? Seems like literally just a few months ago when, just after upgrading my team's codebase to Webpack 2, Webpack 3 came out. Why do front-end application frameworks (e.g. Angular, and even React) and build tools constantly feel the need to reinvent what they just reinvented? Don't people (users and developers alike) recognize and tire of the churn? Stepping back though, a thread like this appears on HN at least once every few months, so I guess this is just par for the course.

darepublic 9y ago
I am staying with webpack ~2 for now, it does everything I need it to do
franciscop 9y ago
Because they learn from mistakes and can make it better the next time! That happens everywhere; except JS world (at least with npm) is very, very new (relatively speaking). Also now there are many more devs than when the older languages came out, so the experimentation is a lot wider.
- nl 9y ago
  I'm not convinced that this is true. In the JS world different layers feel very closely bound and it isn't usually clear at all how to leave out things which are (mostly at some level) optimisations. That isn't great when things go wrong.
- vanderZwan 9y ago
  > Because they learn from mistakes and can make it better the next time! Well, except seemingly learning from the mistakes made when introducing breaking changes. I not being a cynical jerk bashing on WebPack in particular here. I use it every day and am grateful for its existance, and look forward to the point where migrating to version 4 is going to be relatively painless, at which point I'll actually give that another try. But on the whole, it's like nobody in the JS world seems to learn from the mistakes of other JS projects and they have to make them again themselves.

stevebmark 9y ago

According to Webpack's donation site, https://opencollective.com/webpack https://opencollective.com/webpack, the creator of Webpack, "Sokra," made $44,164 off of Webpack development in 2017 (and $9,000 so far in 2018). We're in a new world of sustainable open source software development, enabled by services like Patreon and this one. Maybe it's petty, but as someone who works on several open source projects without reimbursement, I hope that such "hefty" funding leads to better documentation, better community support, and cleaner upgrade paths. Webpack is notoriously fickle and confusing when it comes to configuration, and at a glance Webpack 4 doesn't seem to have helped with that. Although I certainly appreciate performance improvements. Can I request that funds be diverted into community support and enforcing clean writing across documentation pages? That's what Webpack needs most, and has always needed, by far over any core API changes.

dguo 9y ago
You can vote on prioritization here: https://webpack.js.org/vote/ https://webpack.js.org/vote/
sho 9y ago
> the creator of Webpack, "Sokra," made $44,164 off of Webpack development in 2017 While I certainly welcome this new trend I wouldn't exactly call sub-45k "hefty". That's far below what the author could presumably make working for one of the big shops, and doesn't exactly leave much to "divert" if the author has any plans to pay rent, buy food, etc. As stated it's a great and promising trend, but I wouldn't be too hasty in calling for the author to start redistributing a fairly minimal income. That's barely enough for one person, let alone "staff".

thelarkinn 9y ago

PS: I submitted this response also in Reddit for those who come across it twice. It's not meant to be disingenuous (as I'll likely respond to individual comments also), just meant to show what our statement is. Hi all, We appreciate the feedback. So whether you care to know or not I'll explain where we stand as a project for our docs. So in this major release we want to try different ways to impact as many users as possible. So this time we consiously put priority on working directly with framework and tooling authors like angular, react, preact, vue to ensure they were unblocked on implementing v4. With this we decided: since plugins and loaders will also need time, we will give them a month and release our final version without breaking changes from RC. However I as a maintainer orchestrating all of our separate ecosystem, docs, and teams didn't realise we had been behind on contributions and work from our docs and when the 30 day window elapsed v4 shipped as promise. To not hold back v4 with docs is an organizational and communication error on my part and maybe even a side-effect of juggling my full-time job at Microsoft and the 120-140 hours I spend a month on webpack. I'm more then willing to own this, and for anyone frustrated, its on me and I'm sorry. However we grow and improve after any mistakes we make. So, we have some takeaways that we will build on for our next Major Release. A complete migration guide will be a primary shipping dependency for any future Major version of webpack going here forward. We learned that instead of focusing on frameworks as heavily to provide impact and upgrade paths, (which not have all done this yet), that instead focusing on content accessible to everyone is a far more impactful result. For now, we have the PR pending for our docs upgrade and I'll likely spend the majority of my free time ensuring we have it ready to release as soon as possible. Thank you all for being reasonable and patient with this. Major version releases like webpack 4 are much less likely to happen. This major release included the rewrite in our plugin system, which is the cause of incompatible loaders and plugins. We have no plans to rewrite it again as it is exactly where we need it to be in terms of performance, capabilities, etc. Therefore, look to most future Major versions to be less severe and impactful to loaders and plugins. I plan to spend much more focus on ensuring all of our separate teams are communicating for releases by coordinating all hands ship meetings. This ensures that we are on the same page and everyone is aware what each team has a dependency on. We actually only do have one full time engineer. And have attempted to fully fund a documentation team to work on it full time! It takes a considerable amount of effort to do right. And so thanks for understanding while we continue to work on it. Contributions are always welcome along with constructive feedback. Regardless, we appreciate as always support the positive comments we've seen here but also the actionable criticisms. It probably sounds redundant but we really stress the high bar and expectations that are set for us in the ecosystem as so many of you rely on webpack to ship your products and solutions to the web. We will keep on improving as we have since 2012 and hope you all continue to help us along the way. Sean + webpack Team (@TheLarkInn)

isuckatcoding 9y ago

So I found this gist as I was googling for my webpack error. Originally was trying to get the uglify plugin to work. Then I said screw uglify and STILL couldn't get it work. I gave up and ended up using Rollbar.

pacifika 9y ago

Stop guessing start learning. It sounds like the person doesn’t understand what each configuration command does.

GabeRicard 9y ago
I'm the author of the gist. You're exactly right. This was me guessing when I didn't understand the configuration options, because this was my attempt at learning the BETA of webpack 4 without the new docs available.

simon04 9y ago

There's a big webpack 4 documentation update PR in the pipeline: https://github.com/webpack/webpack.js.org/pull/1856 https://github.com/webpack/webpack.js.org/pull/1856

mnm1 9y ago

Angular, brunch, babel, webpack. While not limited exclusively to the JS community, it seems that much of the JS community especially does not care about backwards compatibility or long term support. Piling on new features and re-architecting everything with every major version number, and sometimes even with minor version numbers, seems to have taken over actually creating and maintaining useful products to the detriment of all software that uses such products. Now we end up with software that's dependent on literally un-upgradable components that are no longer supported and in some cases do not even get security patches. With certain breakages, the software cannot be built at all. Perhaps it might not be a bad idea for open source developers to include a small section in their documentation that details their intended philosophy for the future of the software. That way, people don't get duped into using software written by teams that plan to abandon it completely (I'm looking at Angular here) or partially (everything else).

GabeRicard 9y ago

Author of the gist here. Please don't take this as me complaining about webpack 4 in any way. This was me detailing my process of migrating to the webpack 4 BETA in order to provide feedback to the webpack team, and potentially help anyone else out who got stuck on a few things like I did. They're updating the documentation. Webpack is awesome and v4 is a great update and I highly recommend people try it out.

disgruntledphd2 9y ago
I think that this style of blog/info dump is really, really useful and speaks to how I have spent many, many weekends. Even though I don't really use much JS, I still got a real kick out of reading this.
- GabeRicard 9y ago
  Haha. Thanks! I am trying to do this more, just for personal notes about projects. It makes it easier to go back later and remember what the pitfalls were.

Vinnl 9y ago

The upgrade seemed relatively straightforward with the release blog post. Really, it's the fact that many plug-ins will have to be updated that is holding the upgrade back, but that's not that much of a problem: I've simply documented the status of each [0], am following the respective issues/preparing to submit PRs myself if needed, and am meanwhile remaining on v3. [0] https://gitlab.com/Flockademic/Flockademic/issues/306#note_60571871 https://gitlab.com/Flockademic/Flockademic/issues/306#note_6...