I have zero numbers to back this claim up, but I want to venture a guess that 50% if not more of Rails 7 apps going forward are going to use the jsbundling and/or cssbundling gems. Both gems introduce bin/dev to the developer workflow which is great; however, knowledge of this change is buried in the gems’ README files and is not obvious to developers that calling rails s is no longer enough.
What are people’s opinions to including bin/dev in all Rails apps going forward? Even if the app is only importmaps, having that binstub there and building a habit on using it could help with the transition to the bundling gems if needed. This could also be beneficial to other gems that require separate processes to run such as sidekiq, resque, shackapacker, etc.
Yes, I know that. I’m suggesting the possibility of having that be part of Rails proper instead of it being added after the fact via the bundling gems.
I could see a new command added such as rails dev that becomes the encouraged way to get started, and is essentially a hook around bin/dev. This helps make it more discoverable as it could be part of rails —help. It also keeps it separate from rails s which is important as sometimes you don’t want to run all the services in Foreman style, for example, when using pry. I wonder if you could also use an argument to filter “what services get run”. I was working with the Gitlab Dev Kit a few days ago, which included a service launcher command that had this feature, and it was kind of cool.
I wonder if you could also use an argument to filter “what services get run”.
I know that foreman supports this via the formation (-m) flag. I built a small CLI tool a few years ago that basically did this. rails dev would read the procfile and build the formation argument from there if one wasn’t provided by the user. It worked something like this and fit our use case well as it paired nicely with tmuxinator:
rails dev boots all services defined in the application procfile into the foreman process
rails dev --server boots the rails server only (aliases rails s)
rails dev --no-server boots all services to the foreman process except the server
rails dev --services service-a,service-b,service-c pass an explicit formation to the rails dev command
What if bin/dev just called rails server command by default? This way we have a consistent command to use that can be overriden to fit the needs of the app.
I could see that working. My concern is the upgrade/migration path when it comes to introducing css-bundling and/or js-bunding. I suppose their installers could blindly override bin/dev, but those gems could be added any time after the fact when a Rails app is made.
For example: An existing Rails 7 app that adds a bundling gem after the fact, but bin/dev was customized so we wouldn’t want to blindly override it. One option would be for the bundling gem’s installer script to ask the user if they wish to override.
The above breaks down when the user makes a new Rails 7 app and also includes the bundling gems on app creation. The app would create the default bin/dev file and then the install scripts would run for the bundling gems who would then conflict with the default bin/dev…
I’ve really been enjoying utilizing bin/dev, it makes it really simple to know how to boot an app with everything it needs for the local environment. This also makes things a bit simpler when you’re getting someone new up to speed, ideally they just run bin/setup and then bin/dev to start being productive. I wrote a little bit about it and how I’m using it with Redis for instance.
As far as the upgrade/migration path, can we just handle this the same way we do with other generators and prompt to overwrite, diff, ignore, etc?
