Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Vendored pnpm deployments

Đang mở
  • Có gì không ổn?
#957 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@ivanovac đang làm issue này rồi.

Từ ngày 12/10/2026.

  • #964 của @ivanovac — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, node.js
Lĩnh vực
build-system

Hướng nghiên cứu

Start in src/nodejs/supply/supply.go, especially BuildDependencies(), the PNPM interface, and the package-manager selection cases. Compare the existing NPM.Rebuild() implementation in src/nodejs/npm/npm.go; then inspect the supply tests for vendored and pnpm behavior. Done means a vendored pnpm deployment invokes pnpm rebuild rather than pnpm install.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Vendored pnpm deployments run pnpm install instead of pnpm rebuild

Summary

Since v1.9.5 pnpm is officially supported (big thanks) but pnpm projects with a pre-populated node_modules/ (vendored deployments) incorrectly run pnpm install --no-frozen-lockfile instead of pnpm rebuild.
There are two distinct bugs in BuildDependencies().

Bug 1 — case s.UsePNPM has priority over case s.IsVendored

supply.go#L342–L363

switch {
case s.UseYarn:     // L343
    s.Yarn.Build(...)
case s.UsePNPM:     // L348 ← matched first, PNPM.Build() runs
    s.PNPM.Build(...)
case s.IsVendored:  // L353 ← never reached when pnpm-lock.yaml is present
    s.NPM.Rebuild(...)
...
}

When both flags are set:

PNPM.Build() runs pnpm install, ignoring the pre-populated node_modules/.

Bug 2 — case s.IsVendored hardcodes NPM.Rebuild() regardless of package manager

Even if the ordering were fixed, case s.IsVendored at
supply.go#L353
always calls s.NPM.Rebuild(). A vendored pnpm project should call PNPM.Rebuild(),
which would also require adding Rebuild(string) error to the
PNPM interface at L51–L53
(today only Build(string, string) error exists),
mirroring npm/npm.go#L34–L51.

The same gap likely exists for Yarn vendored deployments.

Use case

We use pnpm deploy --prod to produce a flat node_modules/ layout compatible with the CF buildpack, then push the archive.
The buildpack should detect the pre-populated node_modules/ and skip the install phase, running pnpm rebuild instead to recompile any native addons for the CF stack.

How to reproduce
  1. Create a minimal pnpm workspace with a pnpm-lock.yaml and a pre-populated node_modules/.
  2. Run the buildpack supply step.
  3. Expected: pnpm rebuild is called.
  4. Actual: pnpm install --no-frozen-lockfile is called.
Ngôn ngữ chính
Go
Star
173
Fork
389
Merge trung bình
2 ngày 14 giờ
Pull request đã merge (30 ngày)
12

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của cloudfoundry/nodejs-buildpack

Tất cả issue của cloudfoundry/nodejs-buildpack

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.