Repository navigation
Conversation
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.
dshplugin
pushed a commit
that referenced
this pull request
Nov 9, 2026
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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 anddshmarker are currently checked againstlatest, 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>/latestby default,<pkg>/<version>when a version is supplied (leadingvstripped, scoped names encoded).isDshNpmPackageForRepo(..., version): fetch the exact version when provided; unchanged behavior otherwise.install.ts: pass the existingpinVersionto 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 /vprefix / scoped encoding.isDshPackageMetadataForRepotests unchanged.npm test: 260 tests, 258 pass, 2 skipped, 0 fail;npm run typecheckclean.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
repositoryback-link, cache perpkg@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.