Towards the next version v0.3.0

[nikushi]

v0.2.x-trunk

I have made v0.2.x-trunk from the latest released version v0.2.4. I do not intend to actively maintain v0.2.x anymore, except security fixes or bug fixes.

v0.3.0

I am thinking about renaming the project name. Initially the purpose of the gem is integrate with webpack-manifest-plugin, which concept was very simple. After a while I released the gem, I realized that there are some more issues that the gem can solve, such as pre-compilation in test, and hot-reload(HMR) support(which I am not decided to support this though). If the gem support those, I should change the name of the gem.

PRs will be gathered at v0.3.x-trunk branch.

[jakeNiemiec]

You might consider taking a page out of webpack's book, let me explain:

A: The webpackER path has a single gem/module that has too many responsibilities. Some of them are handled well, some are broken because JS moves fast (the issue I commented on before this is a good example).

B: The webpack path contains many modules (eg: the ecosystem of webpack plugins), they each focus on doing one thing well. This approach, in your context, could include:

• a gem that just: resolves via entry name, caches, and serves a webpack file from manifest.json
• a gem that acts as an adapter to use webpack-dev-server with HRM and style injecting
• a gem for specific implementations, like webpacker-react. Currently, fixes in the webpacker repo require a solution that works for every major supported JS framework. A current example of this.

It would be nice if, in the future, webpackER could delegate functionality to small, community-driven modules like this. Eg: If an update to the webpack-dev-server adapter breaks an edge-case for your Vue files, you can just rollback to the last version of the gem it worked in, but still use the latest version of the manifest.json resolver. This flow has worked well for the JS world thus far.

I hope all this makes sense. I haven't gotten a lot of feedback on these ideas, but I have been using them privately in production for over a year now.

---

Let me additionally echo a post I made on the mailing list during webpackER@4 pre-release:

...
WebpackER still makes poor use of webpack's strengths. One-size-fits-all is difficult to maintain the JS world, and many "webpack wrappers" like angular-cli know this well and offer and eject path that many users take. WebpackER is trying to wrap every webpack usecase for React, Elm, Vue, Angular etc.
...
This is not to say Gaurav is not doing a good job. Quite the contrary, webpack@5 is already coming out...webpackER@4 needs all the help it can get to keep up. Wrapping all the major JS frameworks under a single rails-flavored packer is quite the marathon! Keeping up with a single framework's changes is difficult, webpackER is trying to keep up with the needs of many JS frameworks...not to mention mediating inter-package conflicts.

This is why vanilla webpack got so popular. It knows how to be the vehicle without making decisions for you. WebpackER turns what is supposed to be the equivalent of a "Makefile" into yet another "zero-config" framework.

There's the rub, during some crossroads/problem, users will realize that they can cut out the middleman and just write the exact webpack config that they want (it's already generated for them). They don't need to coerce webpackER to output the right config or translate Vue.js README instructions to webpackER compatible instructions.

[nikushi]

Hi, @jakeNiemiec. Thank you for the feedback!

I do not intend to inject much dependencies of node tools to WebpackManifest gem, instead it should be as few dependency as possible. This is because, as you mentioned, the js world moves so quickly. It is very difficult for me to trace such changes. I believe those changes should be controlled by users. For example, if you use Vue.js, creating an app using Vue CLI outside of the gem is enough. Other example is, package installation command(npm or yarn) and their arbitrary options should be configurable by users through the configuration system that will be provided by WebpackManifest.

Also, a plugin system is a nice idea, I might introduce it in the future, but for now I am not sure that there are such a lot use cases to introduce plugin system.

Those advices you presented are very much helpful for me. Thank you!

[jakeNiemiec]

I believe those changes should be controlled by users. For example, if you use Vue.js, creating an app using Vue CLI outside of the gem is enough. Other example is, package installation command(npm or yarn) and their arbitrary options should be configurable by users through the configuration system that will be provided by WebpackManifest.

Would you require users to install npm/yarn themselves? I know webpackER does this for you.

a plugin system is a nice idea, I might introduce it in the future, but for now I am not sure that there are such a lot use cases to introduce plugin system.

I don't think I described my idea properly, let me try one more time:

Instead of making one gem that has many duties, make many gems that each does one duty well. Some would refer to this as a loosely coupled system.

I was trying to relate it to how webpack benefits from having loosely coupled modules in webpack-contrib like sass-loader, css-loader, file-loader. In this way, core webpack does not need to worry about any specific framework. Contrast this with the way webpackER hard-codes framework requirements. This flow directly mitigates the speed of the js world.

If you look at the issue tracker for webpackER, you can see this in action. More than half of the issues on the first page have to do with issues connecting webpackER to other libraries/modules. WebpackER can't keep up, and no non-documentation PRs have been merged in over 45 days. 😞

[nikushi]

I see. I've checked the issues on the webpacker repo. It should be nice if webpacker could have eco-system like the plugin system you mentioned. Does webpacker have a plan to separate it's features to separate gems in the future? I'll watch the activity of webpacker more than now anyway!

[nikushi]

Would you require users to install npm/yarn themselves? I know webpackER does this for you.

yes. You mean here https://github.com/rails/webpacker/blob/master/lib/tasks/webpacker/check_yarn.rake

[jakeNiemiec]

Does webpacker have a plan to separate it's features to separate gems in the future? I'll watch the activity of webpacker more than now anyway!

I don't think so, that's why I try to bring attention to this. Webpacker is the upcoming Rails@6 default replacement for sprockets. I think they are set in their ways, but I still hope it works out.

[nikushi]

I see. Thank you for your all advices! I’ll seriously consider that.

[nikushi]

Renaming has done. v0.3.0 has been released. The gem is now called Minipack.

Thank you for your all advices!