Normalise line endings on the release asset - #7
Merged
Conversation
v1.1.0 shipped as a 297,077-byte download of a 290,824-byte file: 6,253 carriage returns and nothing else. The asset is copied from the working tree, and a Windows checkout has CRLF there. LF is this repo's canonical form -- .gitattributes puts every text file on it via `* text=auto`, with only *.edi and *.txt exempt because there line endings are data. So the CRLF asset matched neither what git stores, nor what the Pages demo serves, nor what CI tested. Staging now normalises, and reports how many bytes it removed so a silent regression is visible in the release output. v1.1.0's published asset is left alone. Replacing it would mean a version number no longer identifies one set of bytes, which is the property step 2 of this script exists to protect. The fix applies from the next release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
v1.1.0 shipped as a 297,077-byte download of a 290,824-byte file — 6,253
carriage returns and nothing else. The release asset is copied from the working
tree, and a Windows checkout has CRLF there.
LF is this repo's canonical form:
.gitattributesputs every text file on itvia
* text=auto, with only*.ediand*.txtexempt because there lineendings are data. So the CRLF asset matched neither what git stores, nor
what the Pages demo serves, nor what CI tested — three copies of the same
app, and the one people download was the odd one out.
Staging now normalises on the way out, and reports how many bytes it removed, so
a silent regression shows up in the release output rather than only in a byte
count someone happens to compare:
v1.1.0's published asset is deliberately left alone. Replacing it would mean
a version number no longer identifies one specific set of bytes, which is the
exact property step 2 of this script exists to protect — its comment says
re-cutting "silently strands everyone who downloaded the first one with a file
that says the same version but isn't the same bytes." The content is identical
either way; only the download is larger than it needs to be. The fix applies
from the next release.
Verified:
node --checkpasses,node web/tests/all.mjsgreen, and thenormalisation was run against the current app — 297,077 → 290,824 bytes, no CR
remaining, version string intact. Step 5 could not be exercised through a dry
run because step 2 correctly refuses an already-released tag.
🤖 Generated with Claude Code