fix(version): honor workspace selection for recursive version bumps#11425
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds ChangesRecursive version workspace selection
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Warning Review ran into problems🔥 ProblemsStopped waiting for pipeline failures after 30000ms. One of your pipelines takes longer than our 30000ms fetch window to run, so review may not consider pipeline-failure results for inline comments if any failures occurred after the fetch window. Increase the timeout if you want to wait longer or run a Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@releasing/commands/src/version/index.ts`:
- Around line 163-170: The fallback selection builds WorkspaceFilter entries
only from opts.filter and treats opts.filterProd as a boolean, so pnpm's
recursive --filter-prod path can ignore patterns in opts.filterProd; update the
logic that constructs the filters array (the WorkspaceFilter push loop) to also
iterate over opts.filterProd when present and push a WorkspaceFilter for each
opts.filterProd pattern (setting filter to the pattern and followProdDepsOnly to
true/!!opts.filterProd), ensuring the fallback selection/pnpm version
--recursive --filter-prod path preserves the requested --filter-prod patterns.
- Around line 155-162: The current logic treats an explicit empty
selectedProjectsGraph ({}) the same as "no graph provided" because it switches
based on graphDirs.length > 0, which causes pkgDirs to fall back to
filterProjectsFromDir() and expand the selection; change the branch to test
opts.selectedProjectsGraph != null (or typeof !== 'undefined') instead of
Object.keys(opts.selectedProjectsGraph).length > 0 so that when
selectedProjectsGraph is explicitly an empty object you still assign pkgDirs =
Object.keys(opts.selectedProjectsGraph) (i.e., honor an intentionally empty
selection) and only call filterProjectsFromDir() when selectedProjectsGraph is
actually null/undefined; update the code around variables graphDirs, pkgDirs and
the call to filterProjectsFromDir() in the same block to reflect this condition.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: f699c69a-3d59-44b7-aca6-9e15a969b53e
📒 Files selected for processing (5)
config/reader/src/configFileKey.tsconfig/reader/src/types.tspnpm/src/cmd/index.tsreleasing/commands/src/version/index.tsreleasing/commands/test/version/index.test.ts
Register --recursive as a global CLI option and reuse selectedProjectsGraph from the CLI workspace filter pass (same idea as publish --recursive). Fall back to filterProjectsFromDir with full workspace options when the graph is absent. Fixes pnpm#11348.
5f603b6 to
840fa9b
Compare
Code Review by Qodo
1. No graph fallback in version
|
840fa9b to
73818f7
Compare
|
Code review by qodo was updated up to the latest commit 73818f7 |
73818f7 to
eaa8eab
Compare
|
Code review by qodo was updated up to the latest commit eaa8eab |
Workspace selection for a recursive run is already computed by the pnpm CLI (main.ts) and handed to the command as selectedProjectsGraph, the same way publish --recursive works. The version handler now bumps exactly those projects instead of re-deriving the selection itself. This removes the in-handler filterProjectsFromDir fallback, which duplicated the CLI's filtering with a different (and incomplete) set of options and was unreachable in production. `@pnpm/workspace.projects-filter` becomes a dev-only dependency (still used by tests). The --recursive flag does not need to be registered as a global option: `@pnpm/cli.parse-cli-args` already recognizes `recursive` (and the `-r` shorthand) for every command, the config reader copies it through to the handler, and the version command already declares it in its own cliOptionsTypes. So the additions to GLOBAL_OPTIONS, pnpmTypes and excludedPnpmKeys are reverted, which also avoids a duplicate-property type error in pack's cliOptionsTypes. Add a pnpm CLI e2e test (test/version.ts) that runs `pnpm version --recursive` and `--recursive --filter` end to end, exercising the real selection wiring rather than a hand-built selectedProjectsGraph.
eaa8eab to
2e2d177
Compare
The recursive happy path and JSON output are now exercised end to end in pnpm/test/version.ts and by the non-recursive JSON test, so the duplicated handler cases are removed. The remaining recursive handler tests cover branches independent of the CLI selection wiring (empty selection, skipping unnamed packages, flag gating).
|
Congrats on merging your first pull request! 🎉🎉🎉 |
|
Code review by qodo was updated up to the latest commit 6d895e9 |
Problem
pnpm version --recursivedid not bump the workspace packages the user selected. In recursive mode the command re-derived the workspace selection itself (viafilterProjectsFromDir) using an incomplete set of options, so it could resolve a different set of packages than the CLI's actual--filter/--recursiveresolution.Fixes #11348.
Change
selectedProjectsGraph— the selection the pnpm CLI (main.ts) already computes from the workspace filter, exactly the waypnpm publish --recursiveworks.filterProjectsFromDirfallback. It duplicated the CLI's filtering logic and was unreachable in production (main.tsalways passesselectedProjectsGraphfor a recursive run).@pnpm/workspace.projects-filterbecomes a dev-only dependency of@pnpm/releasing.commands.--recursive:@pnpm/cli.parse-cli-argsalready recognizesrecursive(and the-rshorthand) for every command, the config reader passes it through to the handler, and theversioncommand already declaresrecursivein its owncliOptionsTypes.Tests
pnpm/test/version.ts— a CLI e2e test that runspnpm version --recursiveandpnpm version --recursive --filter <pkg>end to end, exercising the real selection wiring (parse-cli-args→main.ts→ handler) rather than a hand-built graph.@pnpm/releasing.commandscover the branches that are independent of the CLI selection wiring: an explicitly empty selection bumps nothing (guarding against re-introducing the fallback), skipping unnamed/unversioned packages, skipping the git commit/tag in recursive mode, and non-recursive behavior.Reviewed and revised by Claude (Opus 4.8) at the request of @zkochan.
Summary by CodeRabbit
Bug Fixes
pnpm version --recursivenow correctly honors workspace selection filters when determining which packages to bump. Previously, it would version bump all workspace packages regardless of selection. Now only packages matching the workspace filter are affected, bringing consistency withpnpm publish --recursivebehavior.