fix: default to ['.'] for workspacePackagePatterns when packages field is missing#10996
Merged
fix: default to ['.'] for workspacePackagePatterns when packages field is missing#10996
Conversation
…s missing (pnpm#10927) * fix: restore ['.'] default for workspacePackagePatterns when packages field is missing Commit 6eedf82 removed the ['.'] fallback for workspacePackagePatterns when pnpm-workspace.yaml has no packages field. This caused findPackages to default to ['.', '**'], discovering ALL directories with package.json as workspace projects. This is the same regression that was previously reverted in 595cd41 (close pnpm#10571), reintroduced by pnpm#10127. Projects like cdxgen that use pnpm-workspace.yaml only for settings (e.g. minimumReleaseAge) without a packages field were broken because test data directories were picked up as workspace projects. close pnpm#10909 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: remove unknown word from changeset Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * test(config): verify workspacePackagePatterns defaults to ['.'] without packages field Adds a regression test to ensure pnpm-workspace.yaml without a packages field defaults workspacePackagePatterns to ['.'] (root only), preventing all directories from being discovered as workspace projects. (cherry picked from commit 5163697)
Contributor
Author
|
This seems to be hitting the same issue that #10578 was reverted for. Should that be reverted on |
Member
|
I don't know. I was not the author of the change: #10127 |
Contributor
Author
|
@KSXGitHub any ideas here? I'm just worried that #10909 will become an issue again in v11.0.0. |
zkochan
reviewed
Mar 18, 2026
config/reader/test/fixtures/workspace-yaml-without-packages/pnpm-workspace.yaml
Outdated
Show resolved
Hide resolved
Move the fix from config reader to findPackages, where the overly broad default pattern was the root cause of both pnpm#10909 and pnpm#10571. This keeps workspacePackagePatterns as undefined when packages field is missing, preserving PR pnpm#10127's fix for filter in pnpm-workspace.yaml. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tests now explicitly define workspace packages via pnpm-workspace.yaml and use shared-workspace-lockfile=false to maintain per-project node_modules, matching the pre-change behavior after the findPackages default pattern changed from ['.', '**'] to ['.']. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…change Tests that use preparePackages + filterProjectsBySelectorObjectsFromDir now write pnpm-workspace.yaml with packages: ['*'] before project discovery, since findPackages no longer defaults to scanning all subdirectories. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ot provided Make filterProjectsFromDir consistent with filterProjectsBySelectorObjectsFromDir by reading pnpm-workspace.yaml to get package patterns when none are passed explicitly. Previously relied on findPackages defaulting to ['.', '**']. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Revert the findPackages default back to ['.', '**'] so that behavior is unchanged when there is no pnpm-workspace.yaml. Instead, handle the "workspace yaml exists without packages field" case at the three call sites that read the workspace manifest: - filterProjectsBySelectorObjectsFromDir - filterProjectsFromDir - config.reader getConfig When workspace yaml exists but has no packages field, explicitly use ['.'] (root only). When there is no workspace yaml, leave patterns as undefined so findPackages uses its default ['.', '**']. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…merge The merge of main into this branch lost the `?? ['.']` fallback from commit 844dea8. This caused pnpm-workspace.yaml without a packages field to fall through to findPackages default of ['.', '**'], treating all directories as workspace projects. Reverts the unnecessary changes to findPackages, filterProjectsFromDir, and filterProjectsBySelectorObjectsFromDir, as well as all test file workarounds that were only needed because the fix was in the wrong place. The fix is a single line in config/reader: adding `?? ['.']` when workspaceManifest.packages is undefined. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Member
|
ok, I went full cycle. This solution is correct. |
zkochan
approved these changes
Mar 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #10909.
When
pnpm-workspace.yamlexists without apackagesfield,workspacePackagePatternswas left asundefined, causingfindPackagesto use its default['.', '**']pattern. This treated all directories with apackage.jsonas workspace projects, breaking projects that usepnpm-workspace.yamlonly for settings (e.g.minimumReleaseAge).The fix adds
?? ['.']in the config reader so that a workspace yaml withoutpackagesdefaults to root-only discovery. This was originally fixed in #10927 but lost during a merge.