chore: registry JSON files contain CRLF line endings on Windows, should we add .gitattributes?

[trtlbby]

Summary

When running npm run registry:build (shadcn build) on Windows, the generated public/r/*.json files embed component source code with \r\n (CRLF) line endings inside the "content" strings — even though the source .tsx files themselves use LF. This causes all registry JSON files to appear as modified in git status after every rebuild, even when no actual code changed.

Question: Is this a problem for consumers installing components via the registry CLI? And should we standardize on LF across the repo via .gitattributes?

Environment

• OS: Windows
• Triggered by: running npm run registry:build locally

What's Happening

Every time shadcn build runs on Windows, it reads the .tsx source files and serializes them into the JSON "content" field with \r\n line endings. Git then detects all 11 registry files as modified.

preview
after building shadcn registry

git st after the build

Proposed fix: add .gitattributes

Adding a .gitattributes file at the repo root would normalize line endings to LF for all contributors automatically on git add, regardless of OS:

* text=auto eol=lf
*.json text eol=lf
*.ts   text eol=lf
*.tsx  text eol=lf
*.md   text eol=lf

This means:

• Any file staged via git add gets normalized to LF before it enters the index
• Works for all contributors — no per-machine config required
• Future registry:build runs on Windows will still write CRLF locally, but git add strips it before commit

My Workaround for now

• For Windows contributors, set the following git config at the repo level:

git config core.autocrlf input 

• Then re-normalize all already-tracked files:

git add --renormalize .
git commit -m "chore: normalize line endings to LF"

[!Note]

git config only applies to your local clone. .gitattributes enforces it for everyone.

[github-actions]

Stale issue message