fix: restore default workspace pattern when packages field is missing#10573
fix: restore default workspace pattern when packages field is missing#10573
Conversation
There was a problem hiding this comment.
Pull request overview
Restores the historical ['.'] fallback for workspacePackagePatterns when pnpm-workspace.yaml exists but lacks a packages field, preventing findPackages from defaulting to ['.', '**'] and scanning the entire tree (which can destabilize --frozen-lockfile).
Changes:
- Update
getConfig()to defaultworkspacePackagePatternsto['.']when a workspace manifest exists but has nopackages. - Adjust an existing recursive test fixture to explicitly set
packagesinpnpm-workspace.yaml. - Add a changeset documenting the bugfix for
--frozen-lockfilein this scenario.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
config/config/src/index.ts |
Implements the ['.'] fallback for workspacePackagePatterns when packages is missing but a manifest exists. |
pnpm/test/recursive/misc.ts |
Updates the test workspace manifest to include packages, aligning with the restored default behavior. |
.changeset/petite-laws-share.md |
Adds release notes for the patch fix. |
💡 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 ?? (workspaceManifest ? ['.'] : undefined) | ||
| if (workspaceManifest) { |
There was a problem hiding this comment.
workspaceManifest may be a non-null object without a packages field (e.g. {} or a manifest that only contains other settings). In that case this sets workspacePackagePatterns to ['.'], which makes pnpm treat the repo as a workspace with only the root package. For recursive run/exec/add/test this can result in the workspace root being excluded by default (see the config.workspacePackagePatterns && !config.includeWorkspaceRoot logic), leading to "No projects matched the filters" in what is effectively a single-project repo. Consider avoiding setting workspacePackagePatterns to ['.'] for manifests that don’t define packages (or alternatively ensuring the workspace root is included when the computed patterns are only ['.']).
| pnpmConfig.workspacePackagePatterns = cliOptions['workspace-packages'] as string[] ?? workspaceManifest?.packages ?? (workspaceManifest ? ['.'] : undefined) | ||
| if (workspaceManifest) { |
There was a problem hiding this comment.
This change restores a subtle defaulting behavior that affects workspace discovery and lockfile determinism, but there’s no direct regression test that asserts the new fallback (workspacePackagePatterns => ['.'] when pnpm-workspace.yaml exists without packages) prevents scanning subdirectories. Adding a targeted test (config unit test or pnpm integration test) for a workspace manifest without packages and a nested package.json would help prevent future regressions.
|
These rules are confusing and aren't covered with tests. I can't risk it on v10 branch. I am reverting the previous fix: #10578 |
Closes #10571
Restore the
['.']fallback forworkspacePackagePatternswhenpnpm-workspace.yamlexists but has nopackagesfield. Without this,findPackagesdefaults to['.', '**']and scans all subdirectories, breaking--frozen-lockfile.The fallback is only applied when the manifest is not
null, to keep #10520 working.