[RRFC] Support for `workspace:` protocol (Yarn 2)

[tassoevan]

What / Why

Yarn 2 has a special URL protocol for packages that should be resolved within workspaces: https://yarnpkg.com/features/workspaces#workspace-ranges-workspace Maybe it is related to a bug on Lerna.

When

• n/a

Where

• n/a

How

Try to parse workspace:xyz

Current Behavior

• Throws the error Unsupported URL Type "workspace:": workspace:xyz

Expected Behavior

• Outputs the version described at xyz/package.json.

Who

• n/a

References

• n/a

[ljharb]

I think you may want to file an RFC for this?

[isaacs]

Yes, this needs to be an RFC. Most of the change will be in https://github.com/npm/arborist (for installing) and https://github.com/npm/libnpmpublish and https://github.com/npm/libnpmpack (for publishing).

[joezappie]

I tried searching the npm/rfcs but couldn't find anything on this topic. Google brings you here when googling workspace protocol for npm. Does anyone have a link to where this is being tracked if it was submitted elsewhere?

[lukekarrys]

This has been reopened and transferred to the RFCs repo.

[cawa-93]

The ability to explicitly specify “This package must be in the workspace” reduces potential security risks.

Currently You can't be sure if my-package was taken from the workspace or downloaded from a third-party registry.

[ljharb]

@cawa-93 of course you can; that info is statically determinable and also present in the installed package.json.

[Shakeskeyboarde]

You're both right. But you both mean different things.

@cawa-93 means there's no declarative dependency spec that means "always use the workspace locally, and change to a registry dependency at the workspace version when publishing."

@ljharb means you can achieve the goal imperatively, even if it's not a built in feature.

To enforce proactively, you can use a file: url. But, you have to change this manually just in time for publishing, if it's not a dev dependency. Using a simple version number, especially a fixed version number, could result in pulling down a previous version from the registry, rather than using the local workspace. Alternatively, you could run a check (maybe before testing), to ensure the current dependency version matches the local workspace version. You could also just rely on your versioning tool/process to keep the versions in sync, without checking at all.

To check retroactively (after install/restore), you can use npm commands, or read the lock file, to ensure the dependency was resolved to a workspace, and not the registry.

Both (all) solutions without workspace protocol support require extra/custom steps and tooling. That overhead adds complexity, and introduces failure states that have to be handled by adding/following a stricter and less flexible development process. While process can be a good thing, it requires its own overhead.