Skip to content

fix[faustwp-cli]: resolve blockset globs against the build directory - #2494

Open
eastagiletracker wants to merge 1 commit into
wpengine:canaryfrom
eastagiletracker:agile-board/blockset-glob-project-path
Open

fix[faustwp-cli]: resolve blockset globs against the build directory#2494
eastagiletracker wants to merge 1 commit into
wpengine:canaryfrom
eastagiletracker:agile-board/blockset-glob-project-path

Conversation

@eastagiletracker

Copy link
Copy Markdown

This PR proposes a fix for faust blockset discovering no blocks when the project's own directory path gets parsed as glob syntax instead of as a literal path — the Windows case reported in #1804, and the same silent failure on macOS and Linux whenever a directory name contains a character such as [ or ] (Fixes #1804). We include this PR work along with a full history of your repo at https://eastagiletracker.com/projects/302. You can sign in with your GitHub ID to claim ownership of the project.

What goes wrong

fetchBlockFiles() interpolates FAUST_BUILD_DIR — an OS path derived from process.cwd() — straight into a glob pattern:

return glob(`${FAUST_BUILD_DIR}/**/block.json`, {
  ignore: IGNORE_NODE_MODULES,
});

Everything left of /**/ is then read as pattern syntax rather than as a directory name, and a real project path has two ways of containing syntax. On Windows path.join separates with \, which glob reads as an escape character, so the whole directory prefix collapses into one literal segment that cannot exist on disk:

$ node -e 'const {Minimatch}=require("minimatch"); const p="C:\\Users\\dev\\my-site\\.faust\\build/**/block.json"; console.log(JSON.stringify(new Minimatch(p).set.map((s)=>s.map(String))))'
[["C:Usersdevmy-site.faustbuild","Symbol(globstar **)","block.json"]]

On any platform, a directory named something like my site[1] is read as a character class. Either way fetchBlockFiles() resolves to [], blockset() writes {"blocks": []} to manifest.json, and the command still exits 0 — which is exactly the empty .faust/blocks/manifest.json described in #1804. processBlockFiles() builds its PHP-cleanup pattern the same way, so on those same paths the .php files copied into .faust/blocks/<block> are never stripped and end up inside blocks.zip.

Reproducing it on current canary (402bfd2)

The two tests added here are the reproduction, and they fail against canary's blockset.ts:

$ cd packages/faustwp-cli && npx jest tests/blockset/fetchBlockFiles.test.ts
  ● blockset file discovery › finds compiled block.json files when the project path contains glob syntax
    - Array [
    -   ".../faust-blockset-49j3dC/my site[1]/.faust/build/MyCustomBlock/block.json",
    - ]
    + Array []

  ● blockset file discovery › removes PHP files from processed blocks when the project path contains glob syntax
    Expected: false
    Received: true

Tests:       2 failed, 2 total

I also drove the built CLI end to end against a compiled block on disk, running from the project directory, with a plain directory name as the control:

# cwd = "faust-site[1]"        block.json on disk: block.json, render.php
fetchBlockFiles() : []
# cwd = "faust-site"           block.json on disk: block.json, render.php   (control)
fetchBlockFiles() : [".../faust-site/.faust/build/MyCustomBlock/block.json"]

The change

Both call sites now hand the directory to glob's cwd option and keep the pattern a constant, so the path is treated as data and never parsed:

return glob('**/block.json', {
  cwd: FAUST_BUILD_DIR,
  absolute: true,
  ignore: IGNORE_NODE_MODULES,
});

absolute: true keeps the existing contract intact — processBlockFiles() still receives absolute paths, and the path.dirname/path.basename handling downstream is untouched. This is deliberately not a .replace(/\\/g, '/') on the path: normalising separators would fix Windows and still leave my site[1] broken, while cwd covers both. A changeset is included, per CONTRIBUTING.

Verification

I ran the repo's own checks on a clean canary checkout first, then again with this change: npm test (build plus the @faustwp/core, @faustwp/cli, @faustwp/blocks and @faustwp/block-editor-utils suites), npm run lint, and npm run test:format. All three exit 0 in both runs, with no failures either side. The only difference between the two is the @faustwp/cli suite going from 10 files / 37 tests to 11 files / 39 tests — the two added here, which fail without the blockset.ts change and pass with it. Node 24.15.0, npm 11.12.1.

How this was managed

This work was tracked on a live board built from this repository's own history — 1,524 of your issues and pull requests imported as stories, carrying your 49 labels, with milestones as epics. The story behind this PR is fetchBlockFiles returns empty Array while running faust blockset, and the board it lives on is at https://eastagiletracker.com/projects/302.

board

If you'd rather not receive contributions like this, reply no-more-prs on this pull request and we won't open any further ones on your repositories.


Lawrence W. Sinclair
CEO / East Agile
linkedin.com/in/lwsinclair/
eastagile.com

@headless-platform-by-wp-engine

Copy link
Copy Markdown

Currently, we do not support the creation of preview deployments based on changes coming from forked repositories.
Learn more about preview environments in our documentation.

@changeset-bot

changeset-bot Bot commented Aug 13, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 3565b0f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@faustwp/cli Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[@faustwp/cli] Bug: fetchBlockFiles returns empty Array while running faust blockset on Windows

1 participant