Mention "rake" less in guides

[ghiculescu]

This blog post is about the confusion between bin/rake and bin/rails commands. The two have mostly been aliases since Rails 5, but this means there's all sorts of advice floating around the internet about which command to use. Is rake db:migrate the same as bin/rails db:migrate? I know that it is, but I can see why it's confusing for a first timer.

The blog post's suggestion was to have a section in the guides that introduces rake and talks about this distinction. I'm not sure about this. I think if we take up too much space too early in the guide discussing this, it risks confusing people even earlier. But if the advice is hidden away too much, nobody will find it.

Something I think we should do, though, is mention rake as little as possible in the guides. Mentions in upgrade guides and release notes are fine, but elsewhere we should avoid using it in places where bin/rails does an equivalent job. This PR removes a few rake mentions from the guides. Before doing this, I was expecting there to be a lot more, so this PR turned out to be a bit smaller than expected. Still, every little bit helps I think.

cc @youngbloodcyb

[matthewd]

Agree the mentions of builtins should all use bin/rails and not mention rake.

For custom tasks, though, IMO rake remains the right choice. For a start, the end-user has to define them, so they clearly need to understand that they are rake tasks, and any way that we suggest or imply the usual Rake documentation doesn't apply is a disservice (and/or transfers documentation burden to us).

I don't think we have a discussed-and-established endgame policy, but at least in my head, the long-term goal would be to separate the two commands again. I see the "try for a rake task" fallback behaviour of bin/rails as a transitional mechanism until we eventually get all the built-ins promoted to Rails Commands (which we want, among other things, for the improved ability to take flags and arguments)... after that, I envision a deprecation of the fallback, and ultimately removal.

[ghiculescu]

@matthewd roger that. I undid the changes to the "custom rake tasks" section. How does the rest look?

[p8]

I see the "try for a rake task" fallback behaviour of bin/rails as a transitional mechanism until we eventually get all the built-ins promoted to Rails Commands (which we want, among other things, for the improved ability to take flags and arguments)...

@matthewd I've always wondered if the plan was to migrate all build-ins to Thor.
I agree we should migrate those Thor.
For some of the simpler Rake tasks I've created PRs.

And I gather I can close: #47589 ?

[ghiculescu]

And I gather I can close: #47589 ?

I like this PR too.

[p8]

I like this PR too.

But if we want to have a clear seperation between Rails commands and Rake tasks, is it still beneficial?

[ghiculescu]

Oh, right. Maybe that should be reworded, I'll make a suggestion.

[ghiculescu]

@matthewd is this fine to get merged?