Walkthrough

A new JSR specifier parser crate is created to parse jsr: package specifiers, then integrated into the npm resolver to handle JSR package resolution. The resolver now detects jsr: inputs and routes them through the JSR registry (@jsr) while maintaining unified registry-picking logic and consistent provenance tracking for both npm and JSR resolutions.

Changes

JSR Specifier Resolution

Sequence Diagram(s)

sequenceDiagram
  participant resolve_impl
  participant resolve_jsr_impl
  participant pick_from_registry
  participant PickPackage as PickPackage<br/>Upstream
  participant BuildResult as build_resolve_result

  resolve_impl->>resolve_impl: Check bare_specifier prefix
  alt jsr: specifier
    resolve_impl->>resolve_jsr_impl: JSR dispatch
    resolve_jsr_impl->>pick_from_registry: `@jsr` registry + parsed spec
    pick_from_registry->>PickPackage: Select version from registry
    PickPackage-->>pick_from_registry: meta + version
    pick_from_registry-->>resolve_jsr_impl: {meta, version}
    resolve_jsr_impl->>BuildResult: resolved_via: "jsr-registry"
  else npm or aliased
    resolve_impl->>pick_from_registry: default/aliased registry
    pick_from_registry->>PickPackage: Select version from registry
    PickPackage-->>pick_from_registry: meta + version
    pick_from_registry-->>resolve_impl: {meta, version}
    resolve_impl->>BuildResult: resolved_via: "npm-registry"
  end
  BuildResult-->>resolve_impl: ResolveResult

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested labels

area: resolution

Poem

🐰 I hopped through crates and parsed a string,
jsr: scoped names now wear a new ring.
@jsr/scope__pack is the npm disguise,
Resolvers follow, provenance wise,
Hooray—tests pass with joyful springs!

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

• Port JSR specifier parser from pnpm with error handling
• Wire JSR resolver through @jsr registry with npm-shaped names
• Extract shared picker helper for npm and JSR resolution paths
• Add comprehensive parser and resolver integration tests

JSR specifier parser with error handling

pacquet/crates/resolving-jsr-specifier-parser/src/lib.rs

Parser unit tests ported from pnpm

pacquet/crates/resolving-jsr-specifier-parser/src/tests.rs

New JSR parser crate manifest

pacquet/crates/resolving-jsr-specifier-parser/Cargo.toml

Description

parse_jsr_specifier_to_registry_package_spec returns Ok(None) when the version selector is not a
valid version/range/tag, and resolve_jsr_impl propagates that Ok(None) even though jsr: was
already claimed. This makes the resolver chain treat jsr: inputs as “unsupported by any resolver”
instead of surfacing a JSR parse error.

Code

pacquet/crates/resolving-npm-resolver/src/parse_bare_specifier.rs[R135-138]

Evidence

The adapter explicitly returns Ok(None) on selector classification failure, and the JSR resolver
path returns Ok(None) when that happens. Resolver-base and the default resolver treat Ok(None)
as “not handled”, which leads to SpecNotSupportedByAnyResolverError when the chain is
exhausted—misreporting invalid jsr: specifiers as unsupported.

pacquet/crates/resolving-npm-resolver/src/parse_bare_specifier.rs[126-138]
pacquet/crates/resolving-npm-resolver/src/npm_resolver.rs[135-144]
pacquet/crates/resolving-npm-resolver/src/npm_resolver.rs[206-214]
pacquet/crates/resolving-resolver-base/src/resolve.rs[249-276]
pacquet/crates/resolving-default-resolver/src/lib.rs[45-60]
pacquet/crates/resolving-default-resolver/src/lib.rs[81-83]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
For `jsr:` specifiers, selector classification failure is currently mapped to `Ok(None)`, which semantically means “this resolver doesn’t handle the dependency”. Because `NpmResolver::resolve_impl` eagerly dispatches `jsr:` to `resolve_jsr_impl`, this `Ok(None)` can bubble up to the default resolver and become `SPEC_NOT_SUPPORTED_BY_ANY_RESOLVER`, masking the real cause.

### Issue Context
- `Ok(None)` in the resolver contract means “not handled; try next resolver”.
- `jsr:` is already claimed by `NpmResolver`, so invalid selectors should be a hard error (likely `ERR_PNPM_INVALID_JSR_SPECIFIER`).
- Also consider the empty-selector case (`jsr:@foo/bar@`), which currently can slip through classification as an empty tag.

### Fix Focus Areas
- pacquet/crates/resolving-npm-resolver/src/parse_bare_specifier.rs[126-178]
- pacquet/crates/resolving-npm-resolver/src/npm_resolver.rs[135-214]
- pacquet/crates/resolving-jsr-specifier-parser/src/lib.rs[38-69]

### Suggested change
- Distinguish "non-jsr" from "jsr but invalid selector":
 - Keep `Ok(None)` only for non-`jsr:` inputs.
 - If `parse_jsr_specifier(...)` returned `Some(_)` but `get_version_selector_type(...)` returns `None`, return an `Err(...)`.
- Implement the error as either:
 - a new `ParseJsrSpecifierError::InvalidSpecifier { specifier: String }` with diagnostic code `ERR_PNPM_INVALID_JSR_SPECIFIER`, or
 - a resolver-local error type that is boxed into `ResolveError`.
- Ensure empty selector is rejected (e.g. require `!selector_input.is_empty()` before accepting it as a tag).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

jsr_to_npm_package_name accepts structurally invalid scoped names (empty scope/name or extra /
segments) and still produces an npm package name (e.g. @jsr/foo__ or names containing /). This
violates the npm package-name grammar and pushes bad input into network resolution where it fails
with confusing registry errors instead of a deterministic InvalidPackageName parser error.

Code

pacquet/crates/resolving-jsr-specifier-parser/src/lib.rs[R132-143]

Evidence

The folding helper uses split_once('/') and then directly formats @jsr/{scope}__{name} without
checking empty segments or additional /, which can produce npm names that contradict the repo’s
documented npm package-name grammar; the picker’s package-name validation also won’t reject extra
slashes for scoped names.

pacquet/crates/resolving-jsr-specifier-parser/src/lib.rs[132-144]
pacquet/crates/resolving-npm-resolver/src/registry_url.rs[13-19]
pacquet/crates/resolving-npm-resolver/src/pick_package.rs[582-589]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`jsr_to_npm_package_name` only checks for `@` and the presence of a `/`, but does not validate that the scope and name segments are non-empty and that the name segment contains no additional `/`. This can generate invalid npm package names (e.g. empty name) and defer failure to later network/picker code.

### Issue Context
- JSR specifiers are expected to be `jsr:@<scope>/<name>(@<selector>)`.
- Repo docs already describe npm package-name grammar as allowing only the leading `@scope/` slash.

### Fix Focus Areas
- pacquet/crates/resolving-jsr-specifier-parser/src/lib.rs[132-144]

### Suggested change
- After `split_once('/')`, explicitly reject:
 - `scope.is_empty()`
 - `name.is_empty()`
 - `name.contains('/')`
- Return `ParseJsrSpecifierError::InvalidPackageName { pkg_name: jsr_pkg_name.to_string() }` for these cases.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools