Feature Request: Trust lockfile for vendored pnpm deployments
I maintainer di solito rispondono entro 5 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 55/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- go, node.js
- Ambito
- build-system
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Lingua principale
- Go
- Stelle
- 173
- Fork
- 390
- Merge medio
- 2g 22h
- PR unite (30g)
- 23
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di cloudfoundry/nodejs-buildpack
-
unscheduled
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 62/100
cloudfoundry/nodejs-buildpack#683 ·
I maintainer di solito rispondono entro 5 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
cloudfoundry/nodejs-buildpack#923 ·
I maintainer di solito rispondono entro 5 giorni
-
Misleading "PRO TIP" about missing "package-lock.json" (with `npm-shrinkwrap.json`)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 48/100
cloudfoundry/nodejs-buildpack#852 ·
I maintainer di solito rispondono entro 5 giorni
-
unscheduled
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
cloudfoundry/nodejs-buildpack#655 · 1 commento ·
I maintainer di solito rispondono entro 5 giorni
-
Supply step do not retry when error is connection reset by peerForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertaunscheduled
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
cloudfoundry/nodejs-buildpack#626 · 4 commenti ·
I maintainer di solito rispondono entro 5 giorni
Tutte le issue di cloudfoundry/nodejs-buildpack
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
FiloSottile/age#758 ·
-
nginx configAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 2 giorni
-
fix: the buttons mock cannot take back the match point -- its undo looks only for the running matchApertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
stuttgart-things/zaehlwerk#168 ·
I maintainer di solito rispondono entro 1 giorno