[rush] default NPM command set

[willmtemple]

Is this a feature or a bug?

• Feature
• Bug

Currently, over in the Azure SDK for JavaScript, we have a lot of commands for build/test/etc. that are the same in many packages, but differ slightly in some packages that need to make modifications. It's proven to be very painful to keep these commands in sync across the repository, for example if we want to change the baseline or reference for how a given step should work, we have to apply that change to all the package.json files. While we can automate that process to some degree, it'd be nice to have a "default command set" for commands that are common across the monorepo, but that are still basically just NPM commands.

The proposal is that rushx or Rush bulk commands, when invoked, would check the local package.json commands first, and run a matching command if available, but otherwise fall back to the "default command set," which would be specified at the monorepo level (or perhaps could be overridable on a directory-by-directory basis). I know that this has been discussed before in the repo and generally it seems like a more sophisticated solution based on the documentation-focused Rush commands is preferred (discussion here), but I do think it would be useful to also have a way for NPM-style commands to fall back to defaults.

This would allow us to remove a lot of manually-managed boilerplate from the Azure SDK for JS package.json scripts.

[iclanton]

@octogonz and I were talking about this recently. We're starting to do some work on expanding the way custom commands are executed (see here: #2299).

@willmtemple - Do you have any ideas on what you'd like the config for these default commands to look like?

[willmtemple]

@iclanton If it's going to be something simple and NPM-style rather than the full Rush command system, then my preference would be a top-level key in either rush.json or command-line.json that mirrors the package scripts entry. I think that would be straightforward and would still leave the door open to expanding rushx with Rush-style commands in the future.

One of the things that we really love about using Rush to manage the Azure SDK monorepo is that so far we've been able to avoid having to prescribe a build automation framework like Gulp or Grunt to all of our packages. We just use NPM script conventions, and having a simple system of defaults would make that even easier and better. Most packages can use our default script template, and some that have different needs can change it.

In a perfectly ideal world, there would be no need for this because there would be native support for extension in package.json, that is really all we are trying to accomplish: to keep the DRY principle and eliminate repetition across our configuration.

command-line.json seems to make more sense for where to put it (or maybe even a new file common/config/rush/default-scripts.json) but I'm imagining something like this:

common/rush/command-line.json

{
  ...,
  /**
   * Default scripts for monorepo packages. These scripts are used by Rush bulk
   * commands and `rushx` if no matching script is found in the package's package.json
   * "scripts" entry.
   */
  "defaultScripts": {
    "unit-test:node": "mocha ...",
  },
  ...
}

A more sophisticated solution is also welcome, but that would feel more like a feature, whereas IMO the lack of extension in package.json for a monorepo feels more like something essential that is absent.

[octogonz]

This seems related to Design proposal: "phased" custom commands (Issue #2300). There we pointed out that lots of "scripts" will accumulate in each package.json file, and we proposed to use the rig package system to deduplicate them. npm run will not know to look for scripts in a rig package, but rushx easily could support that. The @rushstack/rig-package library already does most of the work.