chore: normalise line endings to LF on checkout - #996
Merged
Conversation
biome.json already sets "lineEnding": "lf" and CI checks out LF, but nothing made git agree, so a Windows clone got CRLF working files that the tooling did not expect. That gap is what #990 ran into. The README scan anchored its code-fence regex on \n, matched nothing on a CRLF checkout, and left two export checks passing over an empty document. #990 fixed the parse to read either ending; this fixes the divergence itself, for every file rather than the one that surfaced it. The repo is already uniformly LF in the index, so `git add --renormalize .` reports no changes and this adds no content churn.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #990, which I flagged there as worth doing separately.
Why
biome.jsonalready sets"lineEnding": "lf"and CI checks out LF, but nothing made git itself agree. A contributor on Windows gets CRLF working files that the rest of the tooling does not expect.That gap is not hypothetical. It is what #990 ran into: the README scan in
test/public-exports.spec.tsanchored its code-fence regex on\n, so on a CRLF clone it matched nothing, andexports every symbol the README's code examples importandexports every helper a doc comment promises is exposedboth passed over an empty document while looking green. Only the vacuity guard noticed.#990 fixed the parse to read either ending, which is the right fix for that file and holds however the clone happened. This fixes the divergence at the source, so the next scan someone writes does not have to remember.
Scope
img/banner.pngis the only binary file tracked today.text=autoalready detects it correctly; the explicit line keeps that true if more images land.No churn
The repo is already uniformly LF in the index, which is why CI has always been green.
git add --renormalize .after adding the file reports nothing to change, so this rewrites no content and produces no diff on anyone's next checkout of existing files.Verified with
git check-attr: text files resolve totext: auto, eol: lf, andimg/banner.pngresolves totext: unset, binary: set.Checks
npm run lintpasses andnpm testis 246 passing, unchanged from main.I cannot approve my own PR, so this needs a code-owner review before it can merge.