npm
[RRFC] Support for `workspace:` protocol (Yarn 2)
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
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).
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?
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.
@cawa-93 of course you can; that info is statically determinable and also present in the installed package.json.
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.
