An attempt to upgrade to Webpack 4(gist.github.com)
gist.github.com
An attempt to upgrade to Webpack 4
https://gist.github.com/gricard/e8057f7de1029f9036a990af95c62ba8
71 comments
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.
Even though I don't really use much JS, I still got a real kick out of reading this.
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.
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?
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?
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.
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.
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.
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
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.
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.
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.
Yeah.
One day.
PS. I do miss the days when you can just read a book and `man` your way around the dev environment.
I think your ideal exists in backend/SRE roles.
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.
Luckily the bad also comes with the good. Adding and upgrading components off npm in a webpack project is almost always a breeze.
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.
At the end, from all the features your users could care about, your webpack version is not one of them.
> 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.
I did that when webpack 3 was released and now I'm two versions behind.
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.
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.
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.
> 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.
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.
They haven't released webpack 4 yet.
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
[1] https://github.com/webpack/webpack/releases
[2] https://github.com/webpack/webpack.js.org/pull/1905
[0] https://www.npmjs.com/package/webpack
[1] https://github.com/webpack/webpack/releases
[2] https://github.com/webpack/webpack.js.org/pull/1905
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.
It was released 3 weeks ago: https://medium.com/webpack/webpack-4-released-today-6cdb9947...
Yes they have, webpack 4.1.1 is the current version.
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.
>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.
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.
> 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.
Mind elaborating on what you mean by "for optimal use"? For example, I use Brunch with Vue 2 and it seems to work fine.
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.
So, how does vue-brunch work? It declares the Browserify plugin as a dependency, and wraps it.
Exactly this. And Rollup wasn't available (or at least well-publicized) when I was evaluating about a year ago.
Is it weird that I miss gulp and even grunt sometimes?
Why did you stop using them? Gulp is still active. It gets 4M downloads from npm each month. If you like it and it does what you need then you should definitely carry on using it.
Why did you stop using them? Gulp is still active. It gets 4M downloads from npm each month. If you like it and it does what you need then you should definitely carry on using it.
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/pa...
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/pa...
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.
Webpack 4 has been in beta for a while but not enough people tested it on real projects, evidently.
Correct me if I'm misunderstanding the beta process in the javascript ecosystem, but Webpack v4 went into beta on Jan 25 [1] and removed the beta label on Feb 25 [2]. That's not "a while". While I don't want to detract from the work of maintainers—webpack is a great tool that's central to the workflow of thousands—the lack of documentation coupled with an extremely brief beta period gives most of us the impression of a haphazard, half-baked release that we just aren't going to trust for at least several more point releases.
[1] https://medium.com/webpack/webpack-4-beta-try-it-today-6b1d2...
[2] https://medium.com/webpack/webpack-4-released-today-6cdb9947...
[1] https://medium.com/webpack/webpack-4-beta-try-it-today-6b1d2...
[2] https://medium.com/webpack/webpack-4-released-today-6cdb9947...
> Webpack 4 has been in beta for a while
Perhaps the naming is sending the wrong message? "Beta" sounds incomplete and subject to change; I certainly don't make a habit of introducing betas to serious projects unless there's something in them I'm desperate for.
An extended period of Release Candidate versions could give end users more confidence in adoption. This naming implies that the product is finalised and will be released as-is barring serious bugs. It's a small thing, but maybe giving end users the feeling of being early adopters rather than beta testers could increase uptake in this final critical stage.
Perhaps the naming is sending the wrong message? "Beta" sounds incomplete and subject to change; I certainly don't make a habit of introducing betas to serious projects unless there's something in them I'm desperate for.
An extended period of Release Candidate versions could give end users more confidence in adoption. This naming implies that the product is finalised and will be released as-is barring serious bugs. It's a small thing, but maybe giving end users the feeling of being early adopters rather than beta testers could increase uptake in this final critical stage.
Or React's way of avoiding major version cliffs seems to have grown out of this problem.
https://reactjs.org/blog/2016/02/19/new-versioning-scheme.ht... (skip to the major versions and avoiding cliffs part)
https://reactjs.org/blog/2016/02/19/new-versioning-scheme.ht... (skip to the major versions and avoiding cliffs part)
[deleted]
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.
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.
You're not wrong; documentation especially for migrating is poor. Having to google one error at a time is annoying.
[deleted]
Here [0] is a react-router alternative, if you don't need the fancy stuff.
https://medium.com/@daveford/react-router-alternative-switch...
https://medium.com/@daveford/react-router-alternative-switch...
Note that react router 4 does support passing props down explicitly using the "render" parameter instead of component parameter. This was my biggest gripe with previous versions where you had to resort to cloneElement, which is a pain.
OK, so faster builds—and what else? Why not wait until documentation catches up and spare yourself the trouble?
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).
Because I was just trying it out? Are you saying it's wrong to test a beta and provide feedback to the authors?
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.
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.
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.
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.
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.
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.
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.
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.
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?
> 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?
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
[0] https://github.com/webpack/webpack.js.org/issues/1861
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.
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.
Hey Andrew, thanks for the great work on v4.
Webpack is one of these tools I can't imagine working without.
Webpack is one of these tools I can't imagine working without.
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.
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.
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.
> 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.
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.
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.
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.
I am staying with webpack ~2 for now, it does everything I need it to do
According to Webpack's donation site, 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.
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.
> 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".
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".
You can vote on prioritization here: https://webpack.js.org/vote/
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)
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)
Hi Sean.
I certainly didn't mean to bring you down or disparage the work of the webpack team/project in anyway. For me, the way the gist itself was written was just too funny.
Anyways, thank you for all your hard work.
I certainly didn't mean to bring you down or disparage the work of the webpack team/project in anyway. For me, the way the gist itself was written was just too funny.
Anyways, thank you for all your hard work.
I honestly don't feel you did! In fact this gist we actually had from a contributor kind enough to document his experience so we could identify exactly what hot path migration would look like for users. So we were really happy to have this gist created. And we have it tied to our docs PR/issues :)
> Thank you all for being reasonable and patient with this.
Thank you for being reasonable and patient; that's certainly not been the case for "us all" here and on reddit. I've seen some pretty vile and entitled comments.
Unfortunately, release management is hard. I hope you'll get a better grip on it in the future. We all have to learn somewhere, and these things can unfortunately pretty much only be learned in practice.
Thank you for being reasonable and patient; that's certainly not been the case for "us all" here and on reddit. I've seen some pretty vile and entitled comments.
Unfortunately, release management is hard. I hope you'll get a better grip on it in the future. We all have to learn somewhere, and these things can unfortunately pretty much only be learned in practice.
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.
I gave up and ended up using Rollbar.
Stop guessing start learning. It sounds like the person doesn’t understand what each configuration command does.
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.
There's a big webpack 4 documentation update PR in the pipeline: https://github.com/webpack/webpack.js.org/pull/1856
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).
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_6...
[0] https://gitlab.com/Flockademic/Flockademic/issues/306#note_6...
They're updating the documentation. Webpack is awesome and v4 is a great update and I highly recommend people try it out.