openclaw - ✅(Solved) Fix [Bug]: pnpm prune --prod wipes dependencies of installed workspace packages in partial workspaces (pnpm 10) [5 pull requests, 1 comments, 2 participants]

GertjanJ · 2026-03-18T05:39:17Z

[openclaw] Inside a Docker build using pnpm 10, we use an 'opt-in' strategy where only a subset of workspace packages are initially installed via --filter. If… Inside a Docker build using pnpm 10, we use an 'opt-in' strategy where only a subset of workspace packages are initially installed via --filter. If we later add more packages and run pnpm prune --prod, pnpm v10 detects the 'incomplete' workspace and proceeds to wipe the established node_modules of the already installed packages. # PR #52675: fix(docker): avoid pnpm prune in partial workspaces - Repository: openclaw/openclaw - Author: chen-zhang-cs-code - State: closed | merged: False - Link: https://github.com/openclaw/openclaw/pull/52675 ## Description (problem / solution / changelog) ## Summary - Problem: `pnpm prune --prod` on pnpm 10 wipes production dependencies for already-installed workspace extensions once the Docker build copies the full workspace into place. - Why it matters: Docker images built with `OPENCLAW_EXTENSIONS` can ship with missing runtime dependencies, breaking extension-backed deployments. - What changed: added a dedicated `prod-deps` stage that installs production dependencies before `COPY . .`, then copied runtime `node_modules` from that stage into the final image. - What did NOT change (scope boundary): build outputs, extension opt-in behavior, and runtime assets other than how production dependencies are assembled. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [x] CI/CD / infra ## Linked Issue/PR - Closes #49501 - Related #49501 ## User-visible / Behavior Changes Docker builds no longer rely on `pnpm prune --prod` after the full workspace copy, so opted-in extension dependencies stay present in the final runtime image under pnpm 10. ## Security Impact (required) - New permissions/capabilities? (`Yes/No`) No - Secrets/tokens handling changed? (`Yes/No`) No - New/changed network calls? (`Yes/No`) No - Command/tool execution surface changed? (`Yes/No`) No - Data access scope changed? (`Yes/No`) No - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: Windows 11 host - Runtime/container: Docker Desktop (desktop-linux), Node 24 bookworm Dockerfile, pnpm 10.23.0 - Model/provider: N/A - Integration/channel (if any): Docker builds with `OPENCLAW_EXTENSIONS` - Relevant config (redacted): `OPENCLAW_EXTENSIONS=matrix` ### Steps 1. Install production deps for only a subset of workspace packages during the Docker build. 2. Copy the full workspace into the image filesystem. 3. Run `pnpm prune --prod`. ### Expected - Existing production dependencies for the already-installed extension packages remain available in the runtime image. ### Actual - pnpm 10 reconciles against the now-full workspace and wipes the previously installed extension dependencies. ## Evidence Attach at least one: - [x] Failing test/log before + passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) The new `src/dockerfile.test.ts` assertions fail against the pre-fix Dockerfile because it still uses `pnpm prune --prod`, lacks the `prod-deps` stage, and installs prod deps only after `COPY . .`. They pass with this patch. ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: ran `pnpm exec vitest run --config vitest.unit.config.ts src/dockerfile.test.ts src/docker-build-cache.test.ts` successfully. - Edge cases checked: confirmed the prod-deps stage copies opted-in extension manifests before install, runs before the full workspace copy, and is the source of runtime `node_modules`. - What you did **not** verify: attempted a Docker build for `--target prod-deps`, but Docker Hub auth timed out while fetching `node:24-bookworm`, so I did not complete an end-to-end image build in this environment. ## Review Conversations - [x] I replied to or resolved every bot review conversation I addressed in this PR. - [x] I left unresolved only the conversations that still need reviewer or maintainer judgment. If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers. ## Compatibility / Migration - Backward compatible? (`Yes/No`) Yes - Config/env changes? (`Yes/No`) No - Migration needed? (`Yes/No`) No - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: revert this PR's commit to restore the previous single-path dependency flow. - Files/config to restore: `Dockerfile`, `src/dockerfile.test.ts` - Known bad symptoms reviewers should watch for: missing extension runtime dependencies in Docker images, or regressions in the Dockerfile stru

openclaw2026-03-18 05:39:17

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#49501•Fetched 2026-04-08 00:54:35

View on GitHub

Comments

Participants

Timeline

Reactions

Author

GertjanJ

Participants

GertjanJ

Ryce

Timeline (top)

cross-referenced ×5labeled ×2commented ×1

Inside a Docker build using pnpm 10, we use an 'opt-in' strategy where only a subset of workspace packages are initially installed via --filter. If we later add more packages and run pnpm prune --prod, pnpm v10 detects the 'incomplete' workspace and proceeds to wipe the established node_modules of the already installed packages.

Root Cause

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

Steps to reproduce

Create a pnpm workspace with multiple packages.
1. Install dependencies for only a subset of packages (e.g., using --filter).
1. Add the rest of the workspace package directories/manifests to the filesystem (so they appear in pnpm-workspace.yaml).
1. Run pnpm prune --prod.
1. Check the node_modules of the packages installed in step 2; they will be empty.

Expected behavior

pnpm prune should only remove devDependencies from existing installations and leave dependencies intact for the packages that were explicitly installed, even if the rest of the workspace is 'missing' modules.

Actual behavior

The established node_modules are wiped. This behavior seems like a regression or unexpected side effect of how pnpm 10 manages workspace state consistency during pruning.

OpenClaw version

main (2026.3.18)

Operating system

Docker (Node 24 Bookworm)

Install method

Docker

Model

N/A (build-time issue)

Provider / routing chain

N/A (build-time issue)

Config file / key location

No response

Additional provider/model setup details

pnpm Version: 10.23.0
- Workaround: Using pnpm install --prod --offline --filter ... instead of pnpm prune --prod prevents the deletion. This is particularly critical for Docker builds that use a staged 'opt-in' installation strategy for workspace packages.

Logs, screenshots, and evidence

Impact and severity

Affected: Docker builds / VPS deployments using staged installations. Severity: High (wiped dependencies block the runtime). Frequency: 100% repro in partial workspace builds. Consequence: Staged builds fail to run unless the workaround is used.

Additional information

This behavior was observed after upgrading to pnpm 10. Existing Docker builds that used 'pnpm prune --prod' to clean up devDeps after mounting the full source now result in empty node_modules for previously installed packages.

extent analysis

Fix Plan

To fix the issue with pnpm prune --prod wiping the established node_modules of already installed packages in a partial workspace, you can use the following steps:

Instead of running pnpm prune --prod, use pnpm install --prod --offline --filter ... to prevent the deletion of dependencies.
Alternatively, you can also try using pnpm prune --prod --no-workspace-root-check to disable the workspace root check.

Example:

# Install dependencies for a subset of packages
pnpm install --filter package1,package2

# Add the rest of the workspace package directories/manifests to the filesystem

# Run pnpm install with --prod and --offline flags
pnpm install --prod --offline --filter package1,package2

Note: Replace package1,package2 with the actual package names you want to install.

Verification

To verify that the fix worked, check the node_modules directory of the packages installed in the first step. It should not be empty after running the pnpm install command with the --prod and --offline flags.

Extra Tips

Make sure to update your Docker build scripts to use the new command.
If you are using a pnpm-workspace.yaml file, ensure that it is correctly configured to include all the packages in the workspace.
You can also consider pinning the pnpm version to a specific version that works for your use case to avoid future regressions.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

#api #ssr #installation #tensor shape #autograd error #response parsing #generation error #database connection #vector store

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: pnpm prune --prod wipes dependencies of installed workspace packages in partial workspaces (pnpm 10) [5 pull requests, 1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #52675: fix(docker): avoid pnpm prune in partial workspaces

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

PR #52705: fix(docker): avoid pnpm prune in partial workspaces

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

PR #52710: fix(docker): avoid pnpm prune in partial workspaces

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

PR #52726: read: recover from out-of-range offsets

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual