`pnpm run bundle` fails on Windows: the icon-font step finds no SVGs in images/icons

Summary

pnpm run bundle and pnpm run bundle:e2e fail on Windows. The icon-font step reports Error: No SVGs found in ./images/icons while that directory holds 92 SVGs, and --fail-on-warnings turns it into a failed build (exit 2). Everything else — extension, webviews, unit tests — compiles.

Impact

A Windows contributor cannot produce a complete bundle. The extension and webview assets are emitted, but dist/glicons.woff2, dist/glicons.scss and dist/icons-contribution.json are missing and the build exits non-zero, so anything gated on a successful bundle stops there — packaging, bundle:e2e ahead of an E2E run, or a local sanity build.

Linux is unaffected, so CI never sees it and the breakage is invisible to the team until someone builds on Windows.

The error message also points away from the cause: it names a directory that exists and is full of the files it says are missing, so the first guesses are a broken checkout or the wrong Node version.

Validation

Reproduce. On Windows, in a checkout with no dist: run pnpm install then pnpm run bundle:e2e. It exits 2 with No SVGs found in ./images/icons followed by Compiled with problems. The same happens through the standalone npx fantasticon, so it is not specific to the webpack plugin. Deleting dist is what matters: the step is reached on every build.

Cause. [email protected] composes its lookup pattern for the input directory using Node's path join, which on Windows yields backslash separators. The glob major it requires (^13.0.0, resolved to 13.0.6) treats a backslash as an escape character, and the call site passes no option to disable that. Measured against the same directory of 92 SVGs: the pattern as composed on Windows matches 0 files; the same pattern with forward separators matches 92; the same backslash pattern with glob's Windows-paths option enabled matches 92.

Same versions, opposite result per platform. With identical [email protected], [email protected] and Node 22, both on main (30e76c3ad), both with a clean dist and a lockfile in sync:

	Files matched	pnpm run bundle:e2e
Windows 11	0	exit 2, Compiled with problems
WSL2 (Ubuntu)	92	exit 0, icon font generated

Not a Node-version problem. The repo declares engines.node >= 24. The failure is identical on Node 22.20.0 and on Node 24.21.0 — 0 matches against 92 present files in both.

Not reachable from configuration. Node's path join always returns backslash separators on Windows, so no value of inputDir in .fantasticonrc.js avoids it.

The correct artifact is recoverable. Forcing the pattern to use forward separators lets the run complete on Windows, and the dist/glicons.woff2 it produces is byte-identical to the one the Linux build produces from the same commit (md5 539e3c0225310a4aec59d4443e82f49d on both sides). The tracked images/icons/template/mapping.json comes back unchanged.

[email protected] is the latest published version, so there is no upstream release to move to.

Risk

• An already-built font is not a workaround: re-running the build in a checkout that already contains dist/glicons.woff2 still exits 2, because the step regenerates unless the plugin's own codegen-cache record is present, and no checkout examined here has one. On Windows every full build fails — this is not intermittent.
• It can still look intermittent from the outside, because a generated font can be carried between checkouts. Three worktrees on this machine hold one byte-identical glicons.woff2 that predates any successful local generation.
• Skipping icon generation on Windows would leave Windows contributors producing bundles without the icon font, which is worse than a loud failure.