I don’t have the time to document this in detail today but it seems almost like Webpacker is unmaintained at this point. There’s PRs which have not been responded to for months on end, there hasn’t been a commit in a month and a half and a question about the release process/steps to a next release hasn’t been addressed by a team member in almost two months. Given DHH’s recent post on bundling, it seems like webpacker isn’t going to get attention. At the same time, it’s used by a TON of people who have different use-cases than DHH described.
I wanted to post this to hopefully get some feedback from the team as see what the next steps for Webpacker are. I think it’d be helpful to know the following things:
What is the release process for Webpacker? What is holding up a new release?
What is the plan for Webpacker? Is it going to stay part of Rails?
What can interested people in the community do to move the Webpacker project forward? Can non-core Rails team members take on more responsibility and, if so, how?
For now Webpacker will stay part of Rails and will be an alternative to the default setup, that will not use webpack anymore, for apps that need it.
Today Webpacker is already maintained by people outside of the core team. People in the community that wants to move forward the project can help doing the work. They can start opening PRs to fix issues, reviewing existing PRs, giving feedback about what they think they want to see in the next release and what they think are the outstanding issues for a release to happen.
I believe a large part of the OP’s point is that PRs are sitting unmerged without any feedback. I’ve noticed this as well. Webpack 5 has been out for quite some time, and yet webpacker still doesn’t have an official release that supports it, and that is concerning.
You can see that in the rubygems.org page, but it is the Rails Core team and a few more people that have being contributing to webpacker for a while.
They do, but as any volunteer run open source project, people have different priorities and sometimes we don’t have time to spend a lot of time doing what other people want to demand for us.
For what to happen? A release? I’d say someone with release access make releasing webpacker a priority.
Indeed. We usually don’t yank versions so I think we will need to go with a new pre release and use it instead of the beta. I can do that later this week.
About a final release, a few of the contributors want to release but we want to make sure what we have is compatible with the new import maps setup, so we will need to finish that first.
About a final release, a few of the contributors want to release but we want to make sure what we have is compatible with the new import maps setup, so we will need to finish that first.
Could we release a v6 of rails/webpacker almost as-is, and then do a v7 that corresponds to Rails v7?
Totally agree with Justin here, Webpacker 6 have been in beta for a while now and the new import maps setup is a Rails 7 thing. Reading this post from DHH makes me thing that we should still expect some changes of directions before Rails 7 considering all the open questions.
In the meantime, people out there rely on webpacker for their day-to-day-job and can’t really wait for all this to pan out. There’s enough participation and interested to ask the wider community to help taking Webpacker forward, especially if the project will not be a main focus for the Rails core team from now on (having lost its “default” status).
In short: let’s push to release Webpacker v6 with what we have now (which is already a huge improvement and simplification over Webpacker v5) and let’s leave the more philosophical discussions on the future of JS development for Rails 7.
Help the community understand what the plan is for Webpacker v6 and how we can help getting there faster.
I disagree that transpiling of ES6 to older versions of the javascript specification is the core use-case for tools like webpack(er). There is so much more to them, including:
Sprockets lacked (some / most of) these things, thus webpacker was a big, big step forward. Webpacker v6 as a very thin layer above webpack (in contrast to webpacker v5) even more.
Many of these things are quite essential if you have a huge codebase in frontend. It is my opinion that the wide usage of webpack has its reasons that are not mainly rooted in transpiling es6 (which is done in webpacker with babel, as one of many loaders that are used). The advantages lined out here in the mentioned blog post are also achievable with webpack(er).
That aside: The current release v5 of webpacker cannot be run in a safe way, as there are (known) security vulnerabilities. Not directly in webpacker, but in required (core) dependencies of it. The discussion seemed to reach consensus to not fix them but to wait for an v6 release of webpacker that - due to its awesome thin-layer-nature - automatically will resolve them / leave them to solve by the developer of the rails project using webpacker v6.
Worse: If you try to use webpacker v6 right now, you end up automatically with a very, very old release of webpacker v6 (pre.2) that is not even runnable as is. It caused a lot of headache and many hours of time to many users to find out, that beta.7 is actually the most recent v6 version of webpacker. So there are numerous comments on webpacker issues on github that just beg to at least release beta.7 under a different name. We need someone in charge of webpacker that can at least communicate what is needed to push it forward so that the community has even the chance to maintain it. But no one seems to care even if Rails 7 is not here yet and webpacker is currently the default nonetheless.
*edit: changed beta.6 to beta.7, thanks @PikachuEXE
We really need to have Webpacker 6 as is, as soon as possible. Webpacker 7 can be thought to be compatible with the new import maps setup. If there is something that we can do, just let us know. I’m not so expert but I give my all to contribute
I’m using the master branch for a long time and it is really good.
I’ve pushed a rc1 of Webpacker and the npm package today. Please do take that for a spin.
Since Webpacker 6 changes default directories, like using app/packs instead of app/javascript, it’s not a drop-in upgrade we can do for Rails 6.2.x default. But it can certainly be the default for Rails 7.
Webpacker 5.4.2 has also been released with dependencies bumped within their major range, and the loose warning problem solved for new installations. If there are any other concerns with the 5.x series, please note them here, and I’ll get those addressed while I have this in front of me.
We’ll continue to hone on Webpacker 6. It seems close as well, but it would be a manual upgrade for anyone on Rails 6.2.x, due to the incompatible file structures. And then it’d be the default for Rails 7 when you --webpack.
First: Thanks for stepping in and providing an rc-package
These things come to (my) mind:
Are the file structures in app/ really incompatible? They are configurable and configured (by default) in the file config/webpacker.yml. If you upgrade to webpacker 6 but leave your webpacker.yml intact, this should pose no problem. The only change in webpacker.yml should be the file extensions which are removed by webpacker v6, but the project still runs with these.
The problem of upgrading should rather be a matter of the local webpacker (!) config in config/webpack/*, which has changed quite dramatically. Together with the new approach of not requiring most of the dependencies automatically, but leave that up to the developer.
I mentioned it above but I want to highlight it one last time: There are security issues in webpacker v5 (create a vanilla rails application with webpacker and run “yarn audit”). However in “normal” setups these should only affect rails-developers not the end user, but still…
The upgrade is fine. You can leave things as they are there. But that’s not the case for the installer, which will give you a config/webpacker.yml that doesn’t fit what Rails generators expect or what 6.2.x tutorials would talk about.
Please do open PRs with security issues for v5 that we can release on 5.4.x. We just released 5.4.2 with the within-major bumps. But if there are more issues that require major bumps, and you’d like to do the work to verify that these do not pose compatibility issues, we could use the hands
I tried the upgrade process in a branch, following the guide. It was simple enough, but we can’t deploy yet, due to an already reported bug. It breaks random tests when running in our CI.
There’s also a comment about removing babel.js if we never changed it, but no explanation on what to do if we did (which is confusing because step 11 tells us to add to packages.json the preset file that comes with webpacker).
This leaves me wondering if I should add the path to my own babel file to package.json, or leave out that entry and webpacker6 will use my babel file automatically like webpacker5 did.
Also, if anyone wants to solve the loose warning problem in existing installations, after updating you can grab the new babel.config.js from github and replace yours with it.
