[rush] Feature Request: rush scaffold

[EdwardDrapkin]

Is this a feature or a bug?

• [x] Feature
• [ ] Bug

Please describe the actual behavior.

In my experience, organizations (or teams) tend to have preferences for how new projects are created and structured; things like TS configuration, lint configurations, build scripts, folder structure, etc. are usually standardized. Indeed, this is why tools such as yeoman exist. I would intuitively guess that projects in monorepos are likely the most structured and standardized projects.

Because Rush seeks to be a full service, somewhat opinionated solution to managing a monorepo, I was surprised to find that templating new project creation wasn't supported, especially given that Rush can even enforce how projects are grouped together. I believe a scaffolding feature would fit well with the mission of Rush itself (as I understand it) and support a very common behavior in a monorepo environment.

I would suggest adding a common/templates/ folder that is designed to mirror the repository's grouping of projects; for example, if you stored projects such as components/TextInput/, you would have a template for component projects in common/templates/components/. Each template directory should have some kind of template manifest file that describes any template variables it requires and their types, similar to how arguments are provided in command-line.json. Invocation should look something like rush scaffold -t components -n TextInput --vars react=true,webpack=true,newrelic=false (syntax is obviously not important and whatever fits best with the larger ecosystem that I'm fairly new to would be preferable, I'm just not sure what that is). Deeper template nesting should also be supported: rush scaffold -t components/Form/Inputs/Autocomplete -n GoogleMapsAutocomplete.

Rush would then process the templates and create the project as configured. I don't believe, because of the unique circumstance of working in a managed monorepo, that rush scaffold would need to do much more than process string templates and invoke some other rush commands, let alone seek feature parity with something like yeoman.

I'm working on an in-house solution that's quick and hacky, but if the request is accepted, I'd love to volunteer to build this out.

[iclanton]

I really like this idea. We'll need to design this out a little more, but I think this would be really useful.

[EdwardDrapkin]

I had some ideas for potential features that might be helpful, but I was on the fence about including in the original ticket and decided not to:

• Enforce that project folders match a schema of some sort that matches the templates

  • Potential issue: no real standard schema for modeling folder structure
  • Potential issue: duplicate work in creating a schema model of some sort and the template itself
    • Could potentially make sure a folder in a template output directory matches whatever its input has and have a white/black list of other files/folders, which would make the schema unnecessary.
  • Potential issue: would have to be fairly easy to opt out for special cases (legacy projects, new languages, whatever)
  • Would need to support different schemas for different categorical folders
  • Could potentially get very messy with complex monorepo models

• Project type / template hierarchy (e.g. library defines .eslintrc.js.tpl and since web-library is a child, it doesn't need to)

  • Issue easily solved with copy/paste or symlinks, doesn't seem like it's worth the time investment until later when there aren't any low hanging fruit
  • Not sure how popular a use case this would actually be

• Interactive prompt instead of over the top command line flags (particularly with templates with tons of options/variables)

  • Doesn't look like the node-core-library supports interactive prompts (yet?)
  • Not sure what the policy is on adopting something like Inquirer or if that functionality would need to be added to node-core-library

• Dry-run mode

  • Fairly easy to implement, not sure if there's a need/want

I'm not trying to sell these features, just present them as ideas for the design stage, because I'm not sure how much else I can contribute. This has been my first week working with Rush and one of my motivations for wanting to contribute this feature is learning how it works internally so I can advocate for it next year when we launch new projects.

[sdalonzo]

We built something like this using https://plopjs.com/ behind a rush global command. Needless to say, we'd love support baked right into Rush.