Switching to an older Gutenberg pull request leaves trunk-only directories that break wp-build #529

What happens

On a Gutenberg site that was installed on trunk, checking out an older pull request (reproduced with gutenberg#76292, based on March 2026 trunk) and running Apply and rebuild fails in wp-build:

❌ Build failed: Error: ENOENT: no such file or directory, open '<site>/routes/dashboard/package.json'
    at getRouteMetadata (packages/wp-build/lib/route-utils.mjs:48:4)
❌ Build failed: Command failed: wp-build

Why

• routes/dashboard is a route trunk added after that pull request's base. The trunk install created routes/dashboard/node_modules/, which is ignored in both trees.
• Git leaves ignored files alone on a checkout, so after the switch routes/dashboard/ is still there, holding only node_modules. npm install on the pull request does not remove it either: it is not a workspace in that tree.
• wp-build treats every directory under routes/ as a route and reads its package.json.

The same thing happens outside the app: clone, npm install on trunk, git checkout the pull request, npm run build with the system Node fails identically. Checking out the pull request before the first install does not.

Related to #521, which covers the opposite case: files that become untracked after a switch. Here they stay ignored, so the #521 exclude block never sees them.

Workaround

Delete routes/dashboard/ in the site and rebuild. It holds only node_modules, which the next trunk install recreates.

Possible fix

After a switch, remove directories that the new tree does not have and that contain only ignored files (typically a stale node_modules). Open questions: which ignored content is safe to delete (only node_modules?), and whether to do it on every switch or only before a build. Reporting upstream so wp-build skips a directory without package.json is worth doing too, but older pull requests would still carry the old wp-build.

Found while testing #528.