Add bin/dev and Procfile.dev to new Rails apps

[t27duck]

Summary

jsbundling-rails, cssbundling-rails, and tailwindcss-rails all introduce a new bin/dev and Procfile.dev file to the app when they are installed. This is a good thing as it allows developers to run one command to execute their Rails server and frontend build tools.

However, this change in flow is not very obvious to newcomers or even Rails developers with even moderate experience. Up until this point, they've been told to simply run rails s and they can start developing their app. It's not clear with the introduction of the bundling gems they need to run this separate command to get everything going unless they dig into the gems' README files. They are then left wondering why none of their Javascript or CSS changes are applying because its not obvious they have to run a separate process.

This change introduces bin/dev and Procfile.dev to Rails proper as first class citizens added on the defualt app install - regardless of --javascript or --css flags. A --skip-bin-dev flag was added to not generate those files.

bin/dev is identical to the one found in the bundling gems. Their installers will see the identical file and skip it. Procfile.dev includes only the "web" process which is also taken from the bundling gems.

So why even have Procfile.dev if it only has one service in it? If the default workflow of Rails apps going forward uses bin/dev to start/stop the dev stack, this can result in a more smoother transition from importmaps/raw css into the bundling gems as developers would already be using bin/dev. The gems would append to Procfile.dev and no other change would be needed on the developer's part. Also, this allows for other gems such as sidekiq, resque, shackapacker, goodjob, etc (which also need their own separate process while working locally) to slide into the Rails flow easily as one would append a new service to Procfile.dev.

Other Information

Added a changelog entry and did my best to modify some existing guides.

[rafaelfranca]

While I like the idea of matching the same workflow no matter how your app is setup (we do that in shopify using dev and I know GitHub does using binstubs like this one). I don't like that Rails know depends on foreman by default. Here are some reasons:

• Foreman is not updated in 2 years. Maybe it is feature complete, but there are 16 open PRs and 44 issues and no activity in the repository.
• Logs on Foreman are a mess. In development it is important to see the logs of a request, with foreman, if you are using sidekiq your previously server-only logs will be totally mangled by the sidekiq logs.
• Debugging is hard. Since foreman doesn't know to which process send stdin, you can't debug the Rails application without stopping foreman and starting the server alone.

The last two reason in my opinion make the development experience worse than an occasional error when the asset server is not stated.

A better solution in my opinion would add proper error pages for the when the assets server are not started when using one of the other assets gem.

[ghiculescu]

@rafaelfranca would you be open to standardising on a tool that isn't foreman? I don't have a suggestion in mind right now, but I think the PR makes some good points about how most apps these days will eventually need to run multiple processes for comprehensive development (once you start thinking about job queue etc) and it could be good to try and have a 1-command solution for all apps for this.

[dorianmariecom]

+1 on not being to do binding.irb (or equivalent) in a rails server started in foreman

[eileencodes]

would you be open to standardising on a tool that isn't foreman?

I'm not sure there's something simple we can standardize on. When I was at GitHub and we realized foreman wasn't maintained we switched to overmind but it has the same complexities as foreman with Pry and other debuggers and it was often a struggle to explain to teams how to use the debugger. I would not want the Rails issues tracker full of "how do I debug with overmind" questions.

I think we should document this issue and gave an example of how to fix it. That way someone would be opting into making their own Procfile without putting the burden on us to own it.

[nickhammond]

@t27duck Nice work, I've really been enjoying utilizing bin/dev with new apps.

I think this script should be thought of in a similar way as bin/setup. bin/setup comes with every new rails app but it's never modified after the fact at least that I've seen. It's a best recommendation to get a Rails app setup and then it's up to the developer to modify the setup script to better fit their application over time. bin/setup is also never mentioned in the Rails guides or in the docs, it's just an added helper script that you can leverage if you'd like.

While the initial bin/dev will help get things running with a new application they can always fallback to a simple rails s if that's all they want.

I understand the concern around utilizing foreman since it's not actively maintained but then I started looking at what Heroku is utilizing because of their Procfile support. It looks like they're using node-foreman which hasn't been updated since 2018, very few open issues and PRs I'll add though. They then go on to suggest utilizing the foreman ruby gem as an unofficial route. What is a good Procfile manager alternative for local development? Fork the foreman gem and start working through some of those issues? What's everyone else using?

Spurlunking through logs can be fixed in the same way that you'd run docker-compose up, I don't expect to get anything useful out of those logs and often it's booted as a daemon or shoved in a tab and never looked at again. If I want real logs for a service I end up tailing that log with a docker run ... command or in this case a simple tail -f log/development.log or booting it as a standalone process.