Nayan
83b1ab0520
A fresh clone could not build on Windows at all. Three independent causes, reported by @kevin101681 in #11: - check-css.mjs resolved the styles directory with `new URL(...).pathname`, which yields `/C:/Users/...`; readdirSync resolves that against the current drive and looks for `C:\C:\Users\...`. fileURLToPath is also the fix for a latent bug everywhere else: `.pathname` stays percent-encoded, so a checkout under a directory with a space in it fails on macOS and Linux too. - vendor-assets.mjs derived asset names with `from.split("/").pop()`, a no-op on the backslash paths require.resolve returns, so the whole absolute source path was appended to the destination. path.basename handles both separators. - The front-matter regexes in the three gen.mjs scripts were anchored to `^---\n`, and with core.autocrlf=true — the Git-for-Windows default — the markdown specs check out as CRLF, so they reported a missing front-matter block rather than a wrong one. .gitattributes pins every checkout to LF, which prevents the third from recurring. The regexes take `\r?\n` anyway: .gitattributes only applies on checkout, so it does nothing for a clone made before it existed, a zip download, a patch, or an editor configured to write CRLF. sync-readme.mjs had the same defect one step further on, and it was the worse one — it splits on "\n" but rejoins the banner with LF, so on a CRLF tree the --check comparison could never match the file on disk and a Windows contributor had no way to make that CI gate pass.
5 lines
217 B
Plaintext
5 lines
217 B
Plaintext
# Check out everything with LF, even on Windows (core.autocrlf=true would
|
|
# otherwise write CRLF, which breaks the front-matter regexes in the
|
|
# editor-tokens/editor-icons/site-tokens gen scripts).
|
|
* text=auto eol=lf
|