Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Feature Request: Trust lockfile for vendored pnpm deployments

オープン
  • 何か問題がありますか？
#978 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
55/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, node.js
領域
build-system

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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 install instead of pnpm rebuild
主要言語
Go
スター
173
フォーク
390
平均マージ
2日 22時間
マージ済み PR（30日）
23

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

cloudfoundry/nodejs-buildpack のほかの issue

cloudfoundry/nodejs-buildpack の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。