Feature Request: Trust lockfile for vendored pnpm deployments
Los mantenedores suelen responder en 5 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 55/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- go, node.js
- Área
- build-system
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Lenguaje dominante
- Go
- Estrellas
- 173
- Forks
- 390
- Merge medio
- 2 d 22 h
- PR fusionados (30 d)
- 23
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de cloudfoundry/nodejs-buildpack
-
unscheduled
Dificultad 1/5 Menos de una hora Aptitud para principiantes 62/100
cloudfoundry/nodejs-buildpack#683 ·
Los mantenedores suelen responder en 5 días
-
BDSA-2025-12492 CVE-2025-8869Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
cloudfoundry/nodejs-buildpack#923 ·
Los mantenedores suelen responder en 5 días
-
Misleading "PRO TIP" about missing "package-lock.json" (with `npm-shrinkwrap.json`)Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 48/100
cloudfoundry/nodejs-buildpack#852 ·
Los mantenedores suelen responder en 5 días
-
unscheduled
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
cloudfoundry/nodejs-buildpack#655 · 1 comentario ·
Los mantenedores suelen responder en 5 días
-
Supply step do not retry when error is connection reset by peerPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertounscheduled
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
cloudfoundry/nodejs-buildpack#626 · 4 comentarios ·
Los mantenedores suelen responder en 5 días
Todos los issues de cloudfoundry/nodejs-buildpack
Issues similares
-
[Bug]: APIGW request ID headers are inconsistent between server and clientPosiblemente ocupada @zouxingyuks la tomó hoy. Abiertoproduct/backlog
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
TencentBlueKing/bk-nodemgr#3782 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 91/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
praetorianer777/Dynamo#53 ·
Los mantenedores suelen responder en 1 día
-
internal test setup
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
SAP/terraform-provider-scc#430 ·
-
internal test setup
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
SAP/terraform-provider-btp#1743 ·
Los mantenedores suelen responder en 1 día