Feature Request: Trust lockfile for vendored pnpm deployments
Maintainer antworten meist innerhalb von 5 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 55/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- go, node.js
- Bereich
- build-system
Rechercherichtung
Read pnpm.go and the handling of IsVendored around the pnpm rebuild --recursive command. Compare the two proposed trust approaches and check how existing buildpack tests cover vendored pnpm deployments. Done means the maintainers' preferred behavior is implemented and covered for both vendored and non-vendored deployments.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Context
When deploying a Node.js application to Cloud Foundry using pnpm deploy (non-legacy mode),
the generated pnpm-lock.yaml in the deploy directory records tarball URLs from the private
registry used during the CI build (e.g. GitHub Packages, Nexus, Artifactory, etc.).
When the buildpack runs pnpm rebuild --recursive (which is OK),
pnpm re-verifies every lockfile entry against the public registry (registry.npmjs.org).
This fails with:
ERR_PNPM_TARBALL_URL_MISMATCH
because the tarball URLs in the lockfile point to the private registry, not to npmjs.org.
This affects any project that uses a private registry (GitHub Packages, Nexus, Artifactory,
etc.), vendors dependencies via pnpm deploy, and deploys to Cloud Foundry.
Discussion
Option A — --trust-lockfile by default for vendored deployments
In pnpm.go, pass --trust-lockfile to pnpm rebuild whenever IsVendored == true:
cmd := exec.Command("pnpm", "rebuild", "--recursive", "--trust-lockfile")
Rationale: The logic is consistent with the intent of #964 itself. If the buildpack
already trusts node_modules/ enough to skip the install phase, it should equally trust
the lockfile that produced those node_modules/. A vendored deployment is by definition
a pre-audited artifact — the trust boundary is the zip, not the staging container.
Drawback: It removes supply-chain re-verification unconditionally for all vendored
deployments, which may not be desirable for all users.
Option B — Opt-in via environment variable
Introduce a NODE_PNPM_TRUST_LOCKFILE=true environment variable that the user can set
on their CF application when using a private registry:
if os.Getenv("NODE_PNPM_TRUST_LOCKFILE") == "true" {
cmd := exec.Command("pnpm", "rebuild", "--recursive", "--trust-lockfile")
} else {
cmd := exec.Command("pnpm", "rebuild", "--recursive")
}
Set it in manifest.yml or MTA descriptor:
env:
NODE_PNPM_TRUST_LOCKFILE: "true"
Rationale: The buildpack is a generic tool used across many different projects and
organisations. Making trust opt-in keeps the default conservative and lets each team
make an explicit, reviewable decision. The environment variable is visible in the
application manifest, making it auditable.
Summary
| Option A | Option B | |
|---|---|---|
| Implementation effort | Minimal | Minimal |
| Breaking change | No | No |
| Auditable / explicit | No | Yes |
| Works for private registries | ✅ | ✅ |
| Safe as a generic default | ⚠️ | ✅ |
We would be happy to contribute a PR for whichever approach the maintainers prefer.
Related
- #942 — Add pnpm package manager support
- #964 — Fix vendored pnpm deployments calling
pnpm installinstead ofpnpm rebuild
- Vorherrschende Sprache
- Go
- Sterne
- 173
- Forks
- 390
- Ø Merge
- 2 T. 22 Std.
- Gemergte PRs (30 T.)
- 23
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus cloudfoundry/nodejs-buildpack
-
unscheduled
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 62/100
cloudfoundry/nodejs-buildpack#683 ·
Maintainer antworten meist innerhalb von 5 Tagen
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
cloudfoundry/nodejs-buildpack#923 ·
Maintainer antworten meist innerhalb von 5 Tagen
-
Misleading "PRO TIP" about missing "package-lock.json" (with `npm-shrinkwrap.json`)Evtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 48/100
cloudfoundry/nodejs-buildpack#852 ·
Maintainer antworten meist innerhalb von 5 Tagen
-
unscheduled
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 30/100
cloudfoundry/nodejs-buildpack#655 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 5 Tagen
-
Supply step do not retry when error is connection reset by peerEvtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offenunscheduled
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
cloudfoundry/nodejs-buildpack#626 · 4 Kommentare ·
Maintainer antworten meist innerhalb von 5 Tagen
Alle Issues in cloudfoundry/nodejs-buildpack
Ähnliche Issues
-
[Bug]: APIGW request ID headers are inconsistent between server and clientEvtl. vergeben @zouxingyuks hat das heute übernommen. Offenproduct/backlog
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
TencentBlueKing/bk-nodemgr#3782 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 91/100
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
praetorianer777/Dynamo#53 ·
Maintainer antworten meist innerhalb von 1 Tag
-
internal test setup
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
SAP/terraform-provider-scc#430 ·
-
internal test setup
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
SAP/terraform-provider-btp#1743 ·
Maintainer antworten meist innerhalb von 1 Tag