@Betsy_Haibel please do what you think is best!
I have/had the exact same experience, could not have written it any better. I’m slowly coming to terms with “the new way” of handling assets, but you are absolutely right about this being an area where Rails should lead the way, just like in the past.
I don’t think that path is clear enough in new Rails projects today. For example, a fresh rails new on 6.0 comes with a postcss.config.js at the root of the project and app/javascript/packs/application.js that explains how to have images inside app/javascript. This is a bit confusing as it suggests that CSS and images should be processed through Webpack and Sprockets at the same time, in different folders.
Perhaps these should be removed in favor of a clearer migration path in the guides?
Loved this part.
I agree with you, convention-over-configuration is Rails most splendid behavior that just put a spell on me since I wrote the first app. I don’t think Webpack tries to be that way and, if it does, it’s very very distant to achieve that. Maybe I’m wrong, but I see Webpack as a need to organize JS, it was built in the middle of the JS mess. It has inherited the same problems that the whole JS community face which is convention.
4 Likes
On one hand Webpack is a configuration mess and it is capricious beast. But it is decently documented and written about mess you can get familiar with and work with it.
On the other hand my experience with Webpacker trying to hide all this mess and behave “rails way” was a disaster in many cases. To this day I cannot figure out a way for it to properly handle Sass in Vue component files due to well known dart-sass/node-sass conflicts.
I appreciate Webpacker’s attempt to hide all the confusing loaders configuration and setting up some defaults but as soon as you want to tinker with it in any way you are on your own and have to try and hack the config Webpacker generates blindly. This is not very good experience in my opinion. Conventions are great, but without option to easy adjust or even debug them Webpacker is stops being a helpful to and becomes the obstacle you have to dance around.
Our JS team hates it actually and they cannot wrap their heads around it coming from pure webpack background. Some of this is definitely due to lack of proper guide but I don’t believe it will solve or their problems and WTFs.
What I would love to see form Webpacker would be an alternative option to migrate to pure standard webpack configuration and simple integration with rails only for generating manifests and view helpers for including assets. Let the experience JS devs set up the stack they need and want to.
3 Likes
I like the idea of a webpacker “bring your own config” option – it seems like it would provide a good “escape valve” for teams that are getting tripped up by the Webpacker defaults.
1 Like
I know some there were some attempts to do this: https://github.com/rails/webpacker/pull/1916
But AFAIK it did not get enough traction or interest and it’s unfortunate in my opinion. I cannot speak for everyone but I imagine it will be decent workaround to a lot of issues and WTFs JS people have now working around webpacker and it opaque config convention.
1 Like
FWIW You may be interested in a separate project called Minipack that does a minimum Rails integration and allows for projects to “bring your own webpack config”: https://github.com/nikushi/minipack
As for debugging the Webpacker webpack config, I use the following handy one-liner; the JS snippet can be easily modified/manipulated in the Node.js REPL.
RAILS_ENV=development node -e 'console.dir(require("./config/webpack/development"), { depth: null })'
3 Likes
I have the opposite opinion: I would argue Sprockets is better than web packer better for 90% of Rails users, and 100% of Rails newbies. I make my case here: Webpacker presents a more difficult OOB experience for JS Sprinkles than Sprockets did
9 Likes
You have summed up my experience to a T. I believe I’ve tried this exact migration 4 times now and I’m still on sprockets for half of my assets. It’s surprisingly difficult to test out these changes too - though this is not really the fault of Rails, it’s simply a consequence of asset management being very complicated nowadays.
In summary, I’ve sunk about three solid weeks into this migration over the last few years and I still haven’t gotten it right. Hopefully some community members smarter than me can help our documentation out so others in the same situation can fully put this migration behind them. I’m so grateful we have a forum like this to discuss our frustration in a constructive manner. Thank you all for your hard work!
3 Likes
Nothing more to add, apart from we should at least wait for Webpack 5 which is a major change and has been in development for years before making any decision.
1 Like
Not exactly a WTF, but we were surprised to find that webpacker wasn’t built on top of a thin layer that could be the base for integrations with other bundlers. To be clear, it made sense that Rails chose webpack as the bundler on which to build a “full-fledged” integration. But we still thought that if we wanted to use another bundler that we might find a lower layer that just plugged into the existing ActionView helpers.
When we didn’t find such a layer, we took a stab at building one:
I’m curious if this is something Rails would be interested in supporting more formally, though. This kind of underlying layer allows you to swap in your preferred asset bundler in an app in the same way that you can swap mysql for postgres.
7 Likes
I really like your solution. I’m using it in conjunction with npm-pipeline-rails . It’s great that I can mix code in sprockets with other asset bundler code. Thank you.
1 Like
I am using Minipack in preference to Webpacker.
Webpacker was just too opaque, and I had already built webpack configs that worked for my purposes. thanks nikushi
Anita
I tried to use webpacker for CSS (I am using sprockets now).
But a very simple case just beat me & I have no idea how to solve it:
I got an entrypoint_01.scss file with
@import "pages/page_type_01/page";
@import "pages/page_type_02/page";
And both file @import "some_base_style" like what I used to do with sprockets //= require some_base_style
But now I got content of some_base_style.scss repeated
I plan to have more entrypoint_XX.scss files for different groups of page types
And I might move the “import” for different page types around (like manual chunk splitting)
Extracting the common import statements from “pages/page_type_XX/page” would be annoying and error prone
What should I do?
The migration to use webpacker was and is probably the most awful experience in my whole rails career (I’m in rails since Rails 0.7).
We have a quite big and complex rails monolith with multiple entry files and it is a absolute pain to make it work for all our use cases. I really hope there comes a better successor soon (probably wont :)), but webpack and webpacker (which has it’s own confusing bugs, defaults and configuration issues) reallllllly sucks. All members of our development team really hate it to work with webpack*, but since most modern javascript packages are packaged modules it’s not easy anymore to work without it.
I really feel sad when I think about the wasted hours which I had to spend configuring webpack instead of being productive and program “real” stuff.
Sorry, but the experience has been really terrible and I think that webpack should have been included in rails at a later state (when webpack and it’s ecosystem gets really stable). But yeah…
Now we only can improve the guides and it would be great if you could show a way to use webpack(er) with rails engines…
4 Likes
I use webpack - and write my own configuration, including multiple entry points.
If you understand the needs of your monolith and its building blocks you may find this a better option.
You will need to understand webpack - but at least you will be using it directly, not through a (perhaps opaque) proxy.
Anita Graham
1 Like
I am staying on sprockets with many projects near 1M users. I think with webpack security is impossible to maintain topic with a small team. Sprockets is safe by design. I am looking for a solution to use ES6 modules with it.
1 Like
Yes! What bothers me about Webpacker is that it’s just too opaque. Too much is hidden from you, and you don’t know what’s going on, even if you do know Webpack. Minipack looks great.
1 Like
Let me say this, sprockets or webpack - JavaScript is a mess as it is. Yes webpack takes getting used to but actually I think it’s less convoluted than sprockets. But it still feels uneasy especially for people that are ‘not really front end guys’… 
1 Like