Skip to content

fix(install): validate the pinned npm version, not just latest - #679

Closed
PerryLink wants to merge 1 commit into
dshplugin:mainfrom
PerryLink:fix/pinned-version-metadata-20261108
Closed

PerryLink wants to merge 1 commit into
dshplugin:mainfrom
PerryLink:fix/pinned-version-metadata-20261108

Conversation

@PerryLink

Copy link
Copy Markdown

Problem

isDshNpmPackageForRepo() always reads /<pkg>/latest. A catalog install can pin a version (pinVersion — the release-age-safe version, or a self-update target), but the repository and dsh marker are currently checked against latest, not against the version being installed. If a package moved repositories or changed its manifest between versions, the repo→package mapping can be recorded from the wrong manifest.

Change

  • npmMetadataPath(packageName, version): <pkg>/latest by default, <pkg>/<version> when a version is supplied (leading v stripped, scoped names encoded).
  • isDshNpmPackageForRepo(..., version): fetch the exact version when provided; unchanged behavior otherwise.
  • install.ts: pass the existing pinVersion to the check, so a pinned install validates the version it is about to install.

No new workflow, dependency, cache, or gate. The check stays read-only and advisory: a failed check still only skips recording the mapping, as before.

Tests

  • npmMetadataPath: latest / exact / v prefix / scoped encoding.
  • Existing isDshPackageMetadataForRepo tests unchanged.
  • npm test: 260 tests, 258 pass, 2 skipped, 0 fail; npm run typecheck clean.

Boundaries

This does not add ENTRY checks, does not execute any package code, and does not change admission, ordering, or install permissions. It is one metadata lookup, not a ranking or security conclusion.

Follow-up if you want it

This is the smallest metadata piece I could fix in the existing path. If you are open to it, I would like to follow up with the entry-time verifier you described: at ingestion / version change, check npm availability and the repository back-link, cache per pkg@version, and let ENTRY results share the same key. I kept this PR in the install path because the catalog ingestion code is not in this repository; if you can point me at it (or confirm you would take a small module or CLI there), I will send that as a separate, larger PR. That follow-up would also have no new workflow or bundler dependency.

I am not affiliated with the project; this is a factual metadata fix.

isDshNpmPackageForRepo() always read /<pkg>/latest. Catalog installs can pin
a version (pinVersion), so the repository and dsh marker were checked against
latest instead of the version being installed. Add npmMetadataPath() and fetch
the exact version when the install request supplies one; otherwise keep latest.
@yacuo

yacuo commented Nov 9, 2026

Copy link
Copy Markdown
Collaborator

Thanks — this is on main now as squash commit 4f3a560 (version-aware metadata lookup), with a small doc-comment follow-up in a0e74f5. I am closing this PR rather than merging it a second time, so main does not receive a duplicate empty commit. The note about entry-time verification is also the direction we want to take. Appreciate the work.

@yacuo yacuo closed this Nov 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants