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

ruyadorno commented 3 years ago

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

ljharb commented 3 years ago

It seems like anything that npm install accepts should also work here, full stop.

Why would the specifier "type" make a difference if the dependency is in the workspace?

jsg2021 commented 3 years ago

I'm sorry I haven't been available to attend but has this issue seen any movement? @isaacs @ruyadorno

ruyadorno commented 3 years ago

@jsg2021 yeah most definitely there were lots of discussions during the meetings. Long story short, this spawned a larger conversation about revamping the workspaces install algorithm and we're looking to propose these changes as its own RFC.

jsg2021 commented 3 years ago

@ruyadorno thank you for the update. Again, I'm sorry for the delay in responding. This last month has been crazy.

It seams that the larger conversion seems to have hijacked my initial issue: supporting git versioned dependencies within the workspace.

From the rfc meeting I was able to attend, it sounded like @isaacs had an idea for this, like a low hanging fruit.

I really hope we can move forward with this without the larger discussion blocking it. For reference, I'm currently working with a workspace of 50+ projects, with each depending on several of the other projects within the workspace.

As it is now, when installing this workspace I effectively clone each project 10 times over instead of just linking.

I have worked around by adding a post-install script that deletes these extra clones. It's just a minor annoyance for me, since I have a pretty fast internet connection. However, I have a colleague whose only internet option is a cellular tether. This is particularly painful for him.

jsg2021 commented 3 years ago

@ruyadorno @isaacs Could I get a link to look into, so I may make a local patch?

jsg2021 commented 3 years ago

However, I have a colleague whose only internet option is a cellular tether. This is particularly painful for him.

@ruyadorno @isaacs I now have several colleagues on slow internet connections where our workspace install takes over an hour. Skipping the git versioned deps (which are in the workspace) should speed this up tremendously.

boeckMt commented 2 years ago

It would also be great if there was the possibility to specify "variables" or some kind of placeholder. So versions could be set on one place and not have to be managed for each project (workspace). This would be helpful for bigger projects which should share same versions.


$ cat package.json
{
  "workspaces": ["a", "b"],
  "dependencies": {
     "xyz": "^1.2.5"
   },
   "devDependencies": {
     "abc": "^2.0.0"
   }
}

$ cat a/package.json
{
  "dependencies": {
    "xyz": "workspace",
    "bar": "workspace/b",
  },
  "devDependencies": {
     "abc": "workspace"
   }
}

$ cat b/package.json
{
  "dependencies": {
    "bar": "^1.0.0",
  },
  "devDependencies": {
     "abc": "workspace"
   }
}

npm / rfcs