I believe that there would be extraordinary value in documenting exactly what gets added when a framework is installed, and what gets removed when it’s removed. Being forced to make all of these decisions with potentially scary and regrettable consequences down the line is anathema to the Rails doctrine. And it’s shameful things are like this, given that it’s relatively easy to remedy and I thought that the whole reason we endured the pain of modularization around Rails 3.0 timeframe was to make this kind of thing easy.
This documentation is a major step towards being able to dynamically install and remove frameworks as easily as we try out gems. It also lets us move people towards feeling comfortable with Webpacker faster. For example, just asking people if they need jQuery to be available globally as a plugin (so it could be added to package.json and config/webpack/environment.js) would cut down yak shaving dramatically for many people.
Parting thought: I sincerely believe that Turbolinks is one of the best things to ever land in the framework. I feel a visceral pain when I see people talk about removing it by default. What’s needed is education for people who aren’t so comfortable in modern JS to understand why their non-idempotent code is going to break in a re-entrant scenario. Turbolinks isn’t the thing that is broken. Turbolinks is a linter for code that isn’t aging well.
