The issue I have with webpacker is that it pulls too many dependencies…Webpacker’s dependencies (and their dependencies) pulls more than 886k lines of code (886025 to be precise). Given npm’s track record, I am really nervous in adding almost 900k LoC to my project.
Here is a better way of illustrating the dependency creep:
http://npm.anvaka.com/#/view/2d/%2540rails%252Fwebpacker%25404.0.0-rc.7
IMHO, 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.
All this would be fine if the friction caused by these competing flows were handled with care…but, little things like the following go without being addressed.
-All modules from node_modules (including js dependencies that will never be run in browser) suddenly need to get transpiled to “to comply with ES5 standard”.
-PRs warning users of unorthodox changes are closed without comment.
If you didn’t say the magic words, ALL of your node_modules are watched and transpiled by default, now we have a bunch of users running out of memory, can’t deploy, slow build performance. And that’s just pre-release. IMHO, these are un-sensible defaults that can damage the new-user experience.
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.
I wonder if anyone else shares these concerns?
PS: @mansur.mustafayev 900k additional LoC is not worth transpiling JS sprinkles. If I know Rails devs, sprockets will stick around for quite a while. By then, I think webpacker will find its stride.
