Open tassoevan opened 3 years ago
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?
This has been reopened and transferred to the RFCs repo.
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.
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
Where
How
Try to parse
workspace:xyz
Current Behavior
Unsupported URL Type "workspace:": workspace:xyz
Expected Behavior
xyz/package.json
.Who
References