[RRFC] Workspaces: support to version specifiers other than semver ranges

Currently, workspaces only support semver-range version specifiers in order to link a pkg:

Semver ranges when used as version specifiers are primarily used to fetch packages from the configured registry, e.g:

{
  "dependencies": {
    "abbrev": "^1.0.0"
  }
}

The workspaces implementation take advantage of the rather flexible nature of semver-range-matching in order to favor local workspaces symlinking instead of downloading packages from the registry:

$ cat package.json
{
  "workspaces": ["a", "b"] # DEFINE ./a AND ./b PACKAGES AS WORKSPACES
}

$ cat a/package.json
{
  "dependencies": {
    "b": "^1.0.0" # IN THIS CASE B IS GOING TO BE SYMLINKED FROM ./b
  }
}

Other version specifiers

From npm-package-arg we can see that the npm installer supports many other different types of version specifiers:

• git - A git repo
• tag - A tagged version, like "foo@latest"
• version - A specific version number, like "foo@1.2.3"
• range - A version range, like "foo@2.x"
• file - A local .tar.gz, .tar or .tgz file.
• directory - A local directory.
• remote - An http url (presumably to a tgz)

Supporting different version specifiers

Here are some of the initial questions I'd love to get some feedback over here and also during one of our RFC calls:

• Would it be possible to support symlinking workspaces from different types of version specifiers?
• If possible: Should we support all specifiers or only a subset?
• What is currently supported by other tools in the ecosystem (Yarn, pnpm, Lerna) ?

References

Original issue by @jsg2021: https://github.com/npm/cli/issues/1942

Start by reviewing the npm-package-arg result types referenced in the issue and compare how Yarn, pnpm, and Lerna handle workspace linking. Resolve which specifiers should be supported and how local symlinking should behave; the work is done when the RFC has a decided scope and acceptance criteria.