Adds support for the jsr: protocol
#6752
Conversation
|
I published https://github.com/nicolo-ribaudo/yarn-plugin-jsr long time ago -- I don't even remember how my plugin works, but I'm sharing it here just in case you notice anything interesting to integrate in Yarn itself :) |
packages/docusaurus/docs/advanced/01-general-reference/protocols/jsr.mdx
Outdated
Show resolved
Hide resolved
| The `jsr:` protocol fetches packages from the [JSR registry](https://jsr.io/). | ||
|
|
||
| ``` | ||
| yarn add @luca/flag@jsr:2.0.0 |
There was a problem hiding this comment.
pnpm is going with jsr:@luca/[email protected] in the install command. deno add also uses jsr:@luca/[email protected] here. Maybe it's worth aligning?
There was a problem hiding this comment.
I don't know for pnpm but in Yarn’s case the syntax here is "standard". By that I mean that we have a data structure to represent a set of packages, called a descriptor.
Descriptors are a combination of package name and an associated range. As a result, their stringified representation is always <name>@<range>, with range being anything (including jsr:<semver> with this PR).
If we were to support yarn add jsr:@foo/bar@... it'd be slightly annoying because it wouldn't be a descriptor: it'd be just a package range for a remapped dependency (ie without a name).
We have some ways to infer a full descriptor from such "nameless" ranges (we do that for yarn add path/to/archive.tgz for example), but it's a little hardcoded at the moment. It'll be fixed in an overhaul I'm working on, but in the meantime I'd prefer to avoid adding new ones.
All that to say, the foo@jsr:1.0.0 syntax is more coherent with how our commands are designed 😄
There was a problem hiding this comment.
Ok - does this syntax allow importing the latest from JSR? I.e. the equivalent of deno add jsr:@foo/bar? I would like to add this syntax to our docs.
There was a problem hiding this comment.
Good question - at the moment the closest would likely be @foo/bar@jsr:*, but this star is a little verbose, doesn't play well with shells, and is saved as-is in the package.json rather than as caret range 🤔
And unfortunately we can't have @foo/bar@jsr:latest, as latest should be interpreted as a package name here for compatibility with other package managers...
I'll think a little more - perhaps we can't avoid having jsr: as a prefix after all? 😔
There was a problem hiding this comment.
Or add a special yarn jsr add command like in my plugin 😛
There was a problem hiding this comment.
That'd would be an option too! But a separate command would come with usability issues (would require making two yarn add calls to add dependencies when you start a new project, and would require a separate usage page), so I'd tend to prefer the jsr: prefix. I opened #6757 to this effect.
…ls/jsr.mdx Co-authored-by: Luca Casonato <[email protected]>
| if (ident.scope) { | ||
| return `@${scope}/${ident.scope}__${ident.name}`; | ||
| } else { | ||
| return `@${scope}/${ident.name}`; |
There was a problem hiding this comment.
I think JSR does not permit package names without scopes.
There was a problem hiding this comment.
Indeed, but I prefer to treat it as an implementation details, it'd make the code more confusing imo to only support particular codepaths in certain cases.
## What's the problem this PR addresses? My PR at #6752 added support for the `jsr:` protocol, but in a way that didn't allow for running `yarn add jsr:@foo/bar` (or even `yarn add @foo/bar@jsr:1.0.0`), because it was setup as a conversion pass in dependency maps - ie it didn't integrate well with `suggestUtils`. ## How did you fix it? I refactored the code to now use a proper resolver & fetcher. A hack remains (see description of `getResolutionDependencies`); it's a medium-term solution. I have a better fix in mind, but that will require some refactoring of our internals so it'll be deferred until the next major. ## Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an `x` in all the boxes that apply. --> - [x] I have read the [Contributing Guide](https://yarnpkg.com/advanced/contributing). <!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with `yarn version check` and fix with `yarn version check -i` --> - [x] I have set the packages that need to be released for my changes to be effective. <!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. --> - [x] I will check that all automated PR checks pass before the PR gets reviewed.
What's the problem this PR addresses?
I noticed pnpm/pnpm#9358 and figured it'd make sense to support this in Yarn as well.
How did you fix it?
Yarn will natively understand the
jsrprotocol and automatically reroute the dependency to its@jsr-prefixed variant.Still need to add tests.
Checklist