Conversation
This reverts commit 1dbbffb.
There was a problem hiding this comment.
Pull request overview
Reverts the v10.29.1 change around handling empty/packages-less pnpm-workspace.yaml, aiming to address the lockfile regression reported in #10571.
Changes:
- Stop treating an empty/
packages-lesspnpm-workspace.yamlas a case that should makepnpm run -rwork by removing the related test. - Adjust recursive filter behavior in
pnpmCLI when running recursive commands (run/exec/add/test) in a workspace. - Default
workspacePackagePatternsto['.']when the workspace manifest has nopackagesfield, and document the revert via a changeset.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| pnpm/test/monorepo/index.ts | Removes the test that asserted pnpm run -r works with an empty workspace manifest. |
| pnpm/src/main.ts | Tweaks when the CLI auto-adds an exclusion filter for recursive run/exec/add/test. |
| config/config/src/index.ts | Changes defaulting of workspacePackagePatterns when packages is missing to avoid scanning the whole repo. |
| .changeset/upset-badgers-dance.md | Adds release notes describing the revert and linking to the triggering regression. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const workspaceManifest = await readWorkspaceManifest(pnpmConfig.workspaceDir) | ||
|
|
||
| pnpmConfig.workspacePackagePatterns = cliOptions['workspace-packages'] as string[] ?? workspaceManifest?.packages | ||
| pnpmConfig.workspacePackagePatterns = cliOptions['workspace-packages'] as string[] ?? workspaceManifest?.packages ?? ['.'] |
There was a problem hiding this comment.
workspacePackagePatterns is now defaulted to ['.'] when pnpm-workspace.yaml exists but has no packages field (including {} or an empty file). This changes workspace discovery from the previous default (which would search all subdirectories) to root-only, which can effectively make packages required for multi-package repos. If this behavior change is intentional to address #10571, it should be covered with a regression test (e.g. ensure an empty/no-packages workspace manifest does not pull in unrelated test/**/package.json files) and explicitly called out in the changeset/release notes so users know they must add packages: to restore prior behavior.
| pnpmConfig.workspacePackagePatterns = cliOptions['workspace-packages'] as string[] ?? workspaceManifest?.packages ?? ['.'] | |
| const cliWorkspacePackages = cliOptions['workspace-packages'] as string[] | undefined | |
| const manifestWorkspacePackages = workspaceManifest?.packages | |
| pnpmConfig.workspacePackagePatterns = cliWorkspacePackages ?? manifestWorkspacePackages |
| } | ||
| }) | ||
|
|
||
| test('empty pnpm-workspace.yaml should not break pnpm run -r', async () => { | ||
| prepare({ | ||
| name: 'project', | ||
| version: '1.0.0', | ||
| scripts: { | ||
| test: 'echo Passed', | ||
| }, | ||
| }) | ||
|
|
||
| fs.writeFileSync('pnpm-workspace.yaml', '') | ||
|
|
||
| const { stdout, status } = execPnpmSync(['run', '-r', 'test']) | ||
| expect(status).toBe(0) | ||
| expect(stdout.toString()).toContain('Passed') | ||
| }) | ||
|
|
||
| const invalidWorkspaceManifests = [ | ||
| 'pnpm-workspaces.yaml', | ||
| 'pnpm-workspaces.yml', |
There was a problem hiding this comment.
The test that verified behavior with an empty pnpm-workspace.yaml was removed, but there is no replacement test that asserts the intended new behavior (especially the lockfile regression described in #10571). Add a regression test that fails if an empty/no-packages workspace manifest causes pnpm to treat unrelated nested package.json files as workspace projects (which can break --frozen-lockfile and produce huge lockfile diffs).
| Reverted a fix shipped in v10.29.1, which caused another issue [#10571](https://github.com/pnpm/pnpm/issues/10571). | ||
| Reverted fix: Fixed pnpm run -r failing with "No projects matched the filters" when an empty pnpm-workspace.yaml exists [#10497](https://github.com/pnpm/pnpm/issues/10497). | ||
|
|
There was a problem hiding this comment.
The changeset text is hard to interpret as-written (it reads like a “revert of a fix of a fix”) and doesn’t clearly state the user-visible behavior change. Consider rephrasing to explicitly say what changes for users (e.g. how pnpm behaves when pnpm-workspace.yaml exists but has no packages field, and how that relates to the lockfile regression in #10571).
| Reverted a fix shipped in v10.29.1, which caused another issue [#10571](https://github.com/pnpm/pnpm/issues/10571). | |
| Reverted fix: Fixed pnpm run -r failing with "No projects matched the filters" when an empty pnpm-workspace.yaml exists [#10497](https://github.com/pnpm/pnpm/issues/10497). | |
| Restore the pre-v10.29.1 behavior when a `pnpm-workspace.yaml` file exists but has no `packages` field: such a file is now ignored, so commands like `pnpm run -r` run against the current project instead of failing with "No projects matched the filters". This effectively reverts the change made for [#10497](https://github.com/pnpm/pnpm/issues/10497), which had introduced a lockfile regression tracked in [#10571](https://github.com/pnpm/pnpm/issues/10571). |
close #10571