format/no-crlf
Severity: warning · Status: enforced · Applies to: ids/**
What
Files use LF line endings, not the CRLF pair that Windows tools write by default.
Why
Mixed with the LF endings used everywhere else, a CRLF file shows every one of its lines as changed in a diff — including the ones you did not touch. That buries the actual change and makes the history harder to read later.
In an .htaccess there is a second, sharper problem: a stray carriage return at the end of a substitution URL becomes part of the redirect target. The rule looks right and sends clients to a URL with an invisible control character on the end.
Plenty of files in this repository already have CRLF endings.
Wrong
$ file ids/my-project/.htaccess
ids/my-project/.htaccess: ASCII text, with CRLF line terminatorsRight
$ file ids/my-project/.htaccess
ids/my-project/.htaccess: ASCII textHow to fix
Convert the file:
sed -i 's/\r$//' ids/my-project/.htaccessStop it happening again — this tells Git to store LF and convert on checkout:
git config core.autocrlf inputBetter still, install EditorConfig support in your editor — most modern editors have it built in, some need a plugin — and the repository's .editorconfig will handle this for you on every file you save, along with the other whitespace rules.
How to check
Run w3id-check with --rule format/no-crlf to check this rule on its own; without it the tool runs every rule, as the pull request checks do.
node tools/check/bin/w3id-check.js --rule format/no-crlf ids/my-projectTesting your changes covers installing the tool, and what else is worth checking by hand.