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.
I like the idea of having a ./bin/dev
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 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
bin/dev, I also have
bin/local for offline development and
bin/production to run a production env and do performance optimisations
Procfile.dev should be the way forward for rails
For what it’s worth, I made an attempt at this in a Rails PR - https://github.com/rails/rails/pull/44658
debugging with bin/dev is hard
please don’t make it default I love rails server
@joyoy Overmind solves this problem. https://github.com/DarthSim/overmind
On that note, it would be nice if bin/dev used overmind if it finds that it’s installed (falling back to foreman if it’s not).
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?
I also have a hard time debugging with bin/dev. I prefer the simple rails s.
no, i don’t like it and use it never
It seems like if a germ like foreman but that could handle typing in sub processes for binding.irb style debugging then everybody would be happy
I’m a huge fan of bin/dev. It quickly took over my workflow and love the convenience of it. That said, I like @swhudson’s idea of
rails dev --options
Either way, I’m glad it’s here and would love to see it further integrated (live reloading?)