Isn't this a way to invite volatility into the Rails ecosystem? Maybe instead of adding options for webpack, yarn etc. Rails should decouple itself from the front-end so that most of us can use our Preferred approach™
Alternately something in the vein of moonglum's gem [0] should also work but again, as an external lib. not part of Rails.
Yes but that's geared towards building an API (ofc I can strip Rails however I like, dropping whatever I don't use) but it wasn't my main point - the tooling in the JS world changes rather quickly, now, this would imply lots of changes in main Rails just to support all of those external changes hence the volatility part in my comment.
For example looking at the Phoenix framework - they choose by default Brunch [0] but they also let you implement whatever you want.
It's still opinionated but they make it clear is not part of the core framework.
The original commit being linked to is actually for adding optional support for Yarn, which is awesome in itself:
"This add a package.json and the settings needed to get npm nodules integrated in new apps when the --yarn option is used (e.g rails new blog --yarn)."
Isn't this a way to invite volatility into the Rails ecosystem? Maybe instead of adding options for webpack, yarn etc. Rails should decouple itself from the front-end so that most of us can use our Preferred approach™
Alternately something in the vein of moonglum's gem [0] should also work but again, as an external lib. not part of Rails.
[0] - https://github.com/fejo-dk/rails_external_asset_pipeline