Fix `No projects matched the filters` in a pnpm Workspace

Confirm pnpm discovered the package

No projects matched the filters means the selector resolved to zero workspace projects. The package may be excluded by pnpm-workspace.yaml, its package.json may be missing, or the filter may use a folder name instead of the package's declared name.

List the discovered workspaces:

pnpm -r list --depth -1

Compare the output with the name field in the target package's package.json. A selector such as --filter @acme/web uses package identity. A path selector can target a directory, but be precise about the current working directory and quote glob patterns.

Check the manifest and invocation root

Open pnpm-workspace.yaml and verify the package directory matches an included glob. Common errors include packages/ when the app sits under apps/, a leading slash that changes matching behavior, and invoking pnpm from a nested directory while assuming the repository root.

Use a literal path selector as a diagnostic and then settle on the stable package-name selector in CI. If a package was recently renamed, update dependent package manifests and rerun installation so the lockfile reflects the new importer.

Avoid changing a filter to * just to make a script run. That may execute tests or release commands across the entire repository and conceal the naming mistake. Validate the selected package set with a harmless command first, then run the intended task. The filter should make work more targeted without making the target ambiguous.

Debug discovery separately from selector syntax

Use a short diagnostic sequence. First run the workspace list command from the repository root and verify that the expected package appears. If it does not, inspect pnpm-workspace.yaml globs and ensure the directory contains a valid package.json. If it does appear, copy the exact package name into the filter and test with a harmless script. This separates “pnpm never discovered the project” from “the selector does not match it,” which are often conflated when the only visible output is an empty selection.

Check the invocation root as well. A nested package can be the current directory while a developer assumes pnpm is using the monorepo root. Inspect the root selected by pnpm and use an explicit -C path or run the command from the repository root when the workflow depends on root configuration. Relative path filters should be written and tested from that same root. Quote selectors containing wildcards so the shell passes them to pnpm intact.

Make renames and CI selection predictable

When a package is renamed, update its name, dependent manifests, release automation, and developer scripts together. Reinstall with the pinned package manager so the lockfile importer reflects the new identity. A stale filter in CI can silently skip tests if the script treats an empty selection as success, so add an assertion that the expected package count is nonzero for critical jobs.

Avoid removing the filter as a quick workaround. That may run a destructive command against every project or make CI slower while concealing the actual mismatch. After correcting discovery, run the intended task for the target and one dependent consumer. Keep a harmless “list selected packages” step in workflows that publish or migrate packages; it creates an audit trail of what the selector resolved to on that commit.

For large workspaces, also check whether the command is being invoked from a directory where pnpm can find the intended root. A package's local package.json can exist even when the workspace root is missing or the workspace manifest is not checked out. Compare the repository root reported by pnpm with the root you expect, and inspect the current branch for a recently moved package. This gives a reproducible diagnosis instead of a guess based on folder names.

Make critical CI filters assert a nonzero and expected package count. An empty selection can otherwise produce a green job that ran no tests. After a rename, update the package manifest, dependents, release automation, and filters together. Keep a harmless package-list step before publish, migration, or cleanup commands so the selected scope is visible in logs.

When the workspace root itself is not discovered, inspect the current checkout and branch for a missing pnpm-workspace.yaml. A nested package can be perfectly valid while still being outside the workspace. Fix discovery first, then validate the selector with a harmless command; changing the selector before discovery is corrected can hide the real repository-layout error.