[RRFC] workspace-tag-version-prefix config

[ljharb]

Motivation ("The Why")

See npm/cli#4017 (comment) - npm version should be able to work inside workspaces.

Example

See the OP in npm/cli#4017.

I think adding an npm config of workspace-tag-version-prefix, which defaults to [$workspaceName] - which would result in a tag of [foo] v1.2.3, for example - should address the need.

[ben-page]

Would npm version patch --ws result in multiple commits or a single commit with multiple tags?

[ljharb]

I'd expect a single commit with multiple tags.

[ruyadorno]

in case we use a template system, it should probably also contain a value for version

e.g: [$workspaceName] v$workspaceVersion in your original example @ljharb

[wraithgar]

this is a prefix so it's assumed version is the end so [$workspaceName] v

[ruyadorno]

good point @wraithgar I believe you're right, in case it's a prefix, it should just end at the v

[wraithgar]

npm version patch --ws result in multiple commits or a single commit with multiple tags?

Multiple commits

[Kagu-chan]

I'd expect a single commit with multiple tags.

I would like to see that as a default behavior which can be overwritten with a specific flag (like git-single-tag or something along the line).

Possible usecase:

In case of our company project we have a monorepo which deploys an API and releases a npm package (for connecting to this api and several more) at the same time, because they will be no cases where only one of both should be updated - we bundle it in one pipeline with tests and everything related triggered by tags.
Having multiple pipelines (because multiple tags will be generated) would result in longer pipelines due to dependecy testing.

[travi]

in case additional prior art is useful, semantic-release-monorepo uses a pattern of <package-name>-<version> by default, but enables adjusting the format.

example: @scope/package-name-v9.25.0

[jameschensmith]

I would like to suggest the tried-and-true package-spec format (i.e., $workspaceName@ in the context of this issue) for the following reasons (non-exhaustive):

• The format is already used in parts of npm.

• There are monorepos already using the format (e.g., EthereumJS, Gatsby, React Router).

• The tag is much easier to parse for workspace name & semantic version than with $workspaceName- or [$workspaceName] v.

  Example using Posix parameter expansion:

  $ tag="@example/package@1.0.0-beta+exp.sha.5114f85"
  $ echo "Workspace name is '${tag%@*}'" 
  Workspace name is '@example/package'
  $ echo "Workspace version is '${tag##*@}'"
  Workspace version is '1.0.0-beta+exp.sha.5114f85'

Also, this may be out of scope (slightly within scope, since $workspaceName suggests a formatting system), but I would also suggest:

• Using an OS-agnostic approach to the variables used in the format string, such as {workspaceName}.
• Using env variables already provided, such as npm_old_version and npm_new_version (workspace name will need to be newly provided).
• Opting out of prefixes and into a new config convention for greater flexibility. workspace-tag-version-prefix would be workspace-tag-version-format, and tag-version-prefix would be tag-version-format.
  • For backwards-compatibility, defaults could either be unset (preferring tag-version-prefix) or set to something like {npm_tag_version_prefix}{npm_new_version}, where npm_tag_version_prefix may be some new environment set.

None of my suggestions have to be taken in the final form, but I thought I would just brain dump my ideas here to see if anything sticks 😊