Interactive "rails new"

I don’t mind default including everything. This is opinionated framework and making decisions on what to make default and what not is just deeply subjective.

But the truth is that apart from beginners lot of people spend too much time just coposing all the flags to rails new command when starting new application and option to simply run rails new --interactive where you can simply pick those options dynamically will go a long way.

I am dying each time i have to open help message and painstakingly copy/past all flags I need to at the moment.

Plus lack of any simple option for Rspec setup is abomination. I understand it may not preference of some but adding and configuring Rspec and rubocop each time is definitely not fun and developer friendly.

There seems to be a lot of energy around this topic. Summarizing what I’m seeing:

  1. There might be value in grouping some “Rails presets,” like the existing --api flag tries to do.
  2. It can be difficult (or just seem difficult) to enable or disable sub-frameworks like ActionMailbox after the fact. This makes the rails new process unnecessarily fraught.
  3. Picking and choosing which frameworks to exclude in one mega-CLI-command makes assembling that command difficult; an --interactive mode might reduce cognitive load here.
  4. Many people have “personal Rails scaffolds” that they assemble manually. This is something the template feature was intended to address, but something about that feature (discoverability? usability?) makes it seem easier to do this manually.
  5. Many people either really like or really dislike speedup features like Bootsnap and Spring. There is no non-contentious perspective about whether they should be a default.
  6. There’s a lot of division on which Rails frameworks should be included out-of-the-box. Some people favor a slimmed-down perspective because it reduces boot time. Some people favor a a fully-featured perspective because Rails is omakase. When people advocate for a subset, they tend to disagree about which subset is the truly essential one.

1-3 all seem defined enough to break up into feature suggestions. Does anyone here have the energy to work on that?

4 seems like a difficult problem and I’d love to hear more thoughts on it.

for 5 and 6, because I don’t believe we’re going to come to consensus in the space of this thread, I’d like us to focus on achievable wins that will make life easier for all camps. I think that if we focus on making it easier to enable or disable Rails frameworks, it’ll make the question of what needs to be included by default much lower-stakes.

5 Likes

My read on 5 is that it’s a mistake to lump them into the same question.

If you ask how many people wish spring would just go away, you will cut through the lack of consensus: people passionately dislike spring.

Bootsnap seems generally neutral for most devs.

1 Like

Honestly, I like Spring! Trying to get my teammates to practice TDD pre-Spring and the same post-Spring was like night and day. It’s amazing how many hardcore technical arguments people made to avoid saying “20-second boot times annoy me too much for TDD to work for me,” and just as amazing how those arguments melted into the ether once 20-second boot times weren’t a thing any more.

So I’m going to restate my point: the chatter on this forum, and chatter I have seen elsewhere, shows me that people are unlikely to come to consensus on Spring and Bootsnap in the space of this thread. I don’t think it’s productive to argue about their existence here, or whether they should be defaults or not. I do think it’s productive to make it easier to turn them on and off, so that whether they’re defaults can become a less contentious question.

5 Likes

Excellent reply. I really appreciate your perspective.

Great summary, Betsy. I’d like to throw my support behind both an interactive option and a minimal option, as well as better tooling and documentation for adding things you’ve said no to after the fact. While some might think “the list of things installed by default is insane”, it represents my honest and genuine assessment of “what would I need if I started a new application tomorrow?”. I would want, and would use, all the options we’ve included by default. That default, the inclusion of “all the tools”, isn’t likely to change.

But as discussed elsewhere, Rails is a big tent. We have a lot of different usages. It doesn’t bother me in the least that we make it easier to opt out of parts of the default stack. Nobody should ever be forced to use something they don’t want to (but also, as the omakase metaphor implies, it’s worth giving the unagi a second or third try… you might SPRING with joy once you realize that a 3s boot is reduced to 0.3s :smile:).

Let’s make all this happen! We can start it as independent projects. The interactive mode, the minimal mode, the adding-things-back-you-removed options :+1:

23 Likes

I think a solution will probably arise from unifying and/or expanding the Template “API” and the AppBuilder, probably expanding Templates with some of the features from AppBuilder.

A better template API would allow more “stacks” to be expressed and shared as templates, so you could rails new blog -m https://railstemplates.org/oldschool and get a 2008-circa rails app, for example. The Template API is too limited to do that right now.

Perhaps rails new itself could be rewritten to just be a Template if the API were expanded far enough.

The plugin ecosystem around Rails might make it difficult to unify these two APIs, but all of the “pieces” are there to deliver interactive mode, minimal mode, and rails add.

EDIT: I just bought railstemplates.org :sweat_smile:

12 Likes

That sounds like a great idea! If we’re letting you run stuff straight from a URL, we should probably preview what you’re about to run. But do like the idea of expanding the API and making the system itself use it!

5 Likes

Having a rails new --interactive option is a great idea! :+1:

I am also tired of maintaining an ever-growing list of features to exclude :smiley:

For the work I’ve been doing an interactive mode would be more valuable than templates, as every app has different requirements and every team different preferences.

4 Likes

rails new --interactive is really great idea!

It would be really awesome if we have ability to re-add the skipped frameworks. In one of my recent projects, I created the new rails app with rails new my_app --api but later we had to revert the api flag as we also needed rails views in the app.

2 Likes

I have started a draft PR to add support for the new rails command:

rails new --minimal

What exactly are we going to skip? everything… everything?

cc/ @Betsy_Haibel @dhh can someone help make the final call on what exactly is excluded?

Here is the PR:

https://github.com/rails/rails/pull/39282

1 Like

@DHH because there are so many ideas going on in this thread, do you think it would be worth making a Basecamp project or similar to coordinate this work? I think the work-to-be coordinated is fast exceeding what a Discourse thread can support.

I’ve got an idea for adding back gems that were opted-out of:

In the case of core rails gem, like actiontext, we’d simply add install generator that wouldn’t add actiontext to Gemfile (because that’s not needed), but would instead add/uncomment require line to config/application.rb and do any other changes that bin/rails action_text:install does today.

1 Like

Bootsnap has no friction. Devs are neutral because its just there and works. For most aspects, a dev would never realize Bootsnap is even there.

Spring has frictions. Oh you changed an initializer? You better remember to reset your Spring otherwise things won’t behave the way you expect them too (which by the way, why in the hell? I dont remember the details, but i had issues like these). You need to know that Spring exists, and to sometime takes action on it once you realize it is currently messing you up.

This cost of Spring can be offset when there is a good gain from it. Saving n seconds every time you run something is a good way to offset, but if n is too small, say 3 seconds, to me, the cost still outweights the benefit a little bit. When I save 5 to 10 seconds, then it starts to be worth it.

One good thing of Spring is that its easy to install and easy to remove. In my opinion, if Rails started without spring, and when it detected that boot times are slow enough, suggested adding Spring (or tweaking a config somewhere to stop the suggestion), then there would be less hate.

3 Likes

We started this forum in part because that is not true. The ground rules here are that Rails is a big tent. Your experience of Rails may not be someone else’s experience of Rails, and everyone commenting here needs to be respectful of that fact.

Betsy, I’m happy for us to start kicking off issues/PRs for some of these ideas. There’s a clear go-ahead on --minimal and --interactive :+1:

4 Likes

Oh, and also ./bin/rails actionmailer:install along with all the other frameworks you can opt out off with --minimal or --interactive.

5 Likes

Just need a final call on bootsnap, shall we include/exclude?

After that I’m going to start tackling interactive (unless someone has started it already)

I do have some questions around this though.

For a newbie do we want them to add the flag --interactive? For me that does not seem like a nice journey, we have a couple of alternatives:

rails new app_name defaults to interactive

rails new which defaults to interactive

Then we can ask the app name, and every stack they want to include/exclude, skip question or go with the defaults.

EDIT: I’m leaving in bootsnap for now, if you feel otherwise, please let me know!

1 Like

Let’s exclude bootsnap on --minimal; I think that will be principle-of-least-surprise here. Folks who want bootsnap but not the rest of the big modern Rails grab bag can always add it for themselves later.

3 Likes

A big pain point for me is that rails new doesn’t check its inputs in many cases. In others, it provides less feedback than it could. I’d really like an interactive version to model the full domain of rails new options, and give assistance when it’s obviously needed. The current UX is this way because of its architecture of extensive opaque delegation without back-propagation of errors. But we can do things differently in the interactive version.

Examples of UX improvements that we could make in the interactive version:

Silent failure like this should be impossible. Because usually, the mistake is buried in a list of other options, and the incorrect config is discovered much later.

rails new my_app --skip-javascrpt`
      create
      create  README.md
      create  Rakefile
(etc.)

When a user clearly misuses the CLI API like this, we should at least show its synopsis and show how to get help:

$ rails new
No value provided for required arguments 'app_path'

Ditto, because it’s not clear where the app_path should be positioned on the command line:

$ rails new --skip-bundle
No value provided for required arguments 'app_path'
2 Likes