Pick inserted line terminators through line_endings::terminator (#815)

[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Refs #815. This is slice 1 of 2; the issue stays open for slice 2.

Summary

Writers that insert lines into a user's file each hand-wrote "if the text contains any \r\n, use CRLF". This PR adds one rule, utils::line_endings::terminator(text), and routes the 7 copies outside open-PR files through it:

• CRLF file → \r\n;
• LF file, or no break at all → \n;
• mixed file → the existing majority_terminator.

Why (leverage)

• B 0. U 1: slice 2 and children 2–4 of tracking Tracking: classify line endings in one place instead of five drifting rules #814 build on this helper. D 7 hand-written copies of one rule collapse into one. S 0. R L. Score ≈ 16, the best eligible candidate this run. The higher-ranked Finish every vendored revert through one shared helper with an explicit keep policy instead of 12 copied finish blocks #990, Build npm-family vendor ledger entries through one constructor instead of seven literal VendorEntry blocks #922, apply, apply --check and vendor report noManifest (exit 0) when .socket/manifest.json exists but can't be stat'd #998 and Stage prebuilt service archives through one shared helper instead of four per-backend service-copy pipelines #906 all change files that other open PRs change.
• Register row E16 and the living document's {{E16}} passages in doc/04-js-lockfiles.md and doc/05-vendored.md (discussion #560).

What changed

Site	Before	After
formats/gem/hosted.rs converge_gem_lock_source (hosted Gemfile.lock pin)	inline any-CRLF	terminator
redirect/upstream/composer.rs (composer.lock dist/source restore)	inline any-CRLF	terminator
redirect/upstream/pypi.rs (requirements --hash continuation restore)	inline any-CRLF	terminator
redirect/pipenv.rs format_entry (Pipfile.lock forward and restore)	inline any-CRLF	terminator
utils/python_script.rs replace_script_metadata (PEP 723, forward and restore)	inline any-CRLF	terminator
vendor/go_mod_edit.rs append + join_preserving_trailing_newline	common::detect_eol ×2	terminator

Deleted: the 6 inline copies and both go_mod_edit calls to detect_eol. Production: about +25 / −12 lines. Tests: about +100 lines. Goldens: about 240 lines re-blessed.

Left for slice 2 (every site sits in a file another open PR changes): vendor::common::detect_eol and its callers (go.sum, requirements, yarn classic), pypi_uv::newline_of, maven_reactor.rs ×2, redirect/mod.rs, the crlf flags in upstream/cargo.rs, npmrc.rs and pypi_pipenv.rs, and Gradle's first-line newline_of. Upstream gem's restore_manifest is deliberately left out too: manifest_blocks_restore_in_place pins CRLF output for a CRLF Gemfile that holds an older rewriter's LF block, so it has to move together with its forward Gemfile writer in redirect/mod.rs.

Behavior

• LF-only and CRLF-only files: none. terminator agrees with the old rule whenever the file isn't mixed.
• Mixed-ending files (the change Pick the line terminator for spliced lines through one line_endings::terminator #815 asks for): inserted lines now take the majority style. Before, a single \r\n anywhere made every inserted line CRLF. The two rules differ only on a mixed file whose majority is LF. A mixed LF-majority composer.lock now unwinds byte for byte; before, its restored dist block came back CRLF.
• Goldens: the go and uv equivalence generators turn one input in five into a mixed file (every 4th line CRLF), so those cases moved: 194 of 300 golang_rewrite chunks (plus 13 more from the follow-up below) and 19 of 300 python_lock_rewrite chunks (20 cases per chunk). No LF-only or CRLF-only case can move, per the rule above.
• No change to JSON output, error codes, exit codes or the CLI contract.

Test evidence

• New tests, all on mixed inputs:
  • unit tests: terminator_follows_the_file_and_the_majority_when_mixed, formatted_entry_takes_the_majority_line_ending, replaced_metadata_takes_the_majority_line_ending, mixed_go_mod_append_takes_the_majority_line_ending, restored_hash_continuation_takes_the_majority_line_ending;
  • tests/upstream_restore_golden.rs: composer_mixed_line_endings_restore_in_the_majority_style (byte-exact round trip) and gem_lock_pin_on_a_mixed_lock_takes_the_majority_terminator.
• Red → green: with terminator temporarily given the old "any CRLF" rule, all 6 per-site tests fail (4 lib + 2 integration). With the new rule, all pass.
• cargo test -p socket-patch-core --lib: 5667 passed, 4 failed. All 4 are the known root-only sandbox failures that also fail on main: relax_loop_must_not_traverse_symlinked_root, an_unremovable_hidden_lock_keeps_every_store_entry, wire_write_failure_maps_error_and_leaves_lock_untouched, wire_failure_rolls_back_already_written_files. After the follow-up, the go/golden/equivalence subset passes 248/248.
• cargo test -p socket-patch-core --test upstream_restore_golden: 50 passed.
• cargo clippy --workspace --all-features -- -D warnings: clean, before and after the follow-up.
• rustfmt: every touched file is rustfmt-clean.
• Not run locally: cargo test --workspace --all-features, because linking all ~235 CLI test binaries filled the sandbox disk. CI covers the CLI suites.

Review follow-up

• Bugbot (311462c): on an LF-majority go.mod whose trailing blank line is CRLF, the append missed the blank and wrote a second one. Fixed in 6b72d7f: the append detects a trailing blank whichever break spells it. Covered by an extra case in mixed_go_mod_append_takes_the_majority_line_ending. Bugbot is clean on 6b72d7f.
• CI on 6b72d7f: 415 of 416 checks passing or skipped at hand-off, with one Gradle e2e leg still running. The ci-ok failure on 311462c is the aggregator of runs cancelled by the 6b72d7f push.

Risk

Low. Seven one-line call-site swaps behind a 6-line pure function. The only behavior change is on mixed-ending files, as #815 specifies. The wrappers (npm/, pypi/, gem/) are unaffected.

🤖 Generated with Claude Code

---

Note

Low Risk
Behavior change is limited to mixed line-ending files; uniform LF/CRLF paths match the old rule. Wide but shallow call-site swaps with strong test/golden coverage.

Overview
Introduces line_endings::terminator as the single rule for which break style writers use when inserting lines: pure CRLF → \r\n, pure LF (or no breaks) → \n, mixed files → existing majority count (ties → LF).

Replaces seven ad hoc contains("\r\n") / detect_eol call sites (Gemfile.lock converge, Pipenv lock formatting, composer.lock restore, requirements hash continuations, PEP 723 metadata re-commenting, go.mod append/join) so a lone CRLF line no longer forces all new lines to CRLF on LF-majority mixed files.

go_mod_edit also treats a trailing blank line as present when its break is the minority style, avoiding a double blank before an appended replace directive.

Adds targeted unit/integration tests for mixed inputs and re-blesses golang / python lock equivalence goldens where mixed-ending fixtures changed outputs.

^{Reviewed by Cursor Bugbot for commit 47a45fa. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 47a45fa. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] native (ubuntu-latest, 1.3.9) on 47a45fa failed one Bun backtest cell: workspace vendored (refusalCodesExact). The other 52 cells in that job passed. This doesn't look like this PR's failure:

• The diff only changes the gem, composer, pypi, pipenv, PEP 723 and go.mod line-terminator writers. It touches no Bun or npm-workspace code.
• The same job passed on 6b72d7f, this PR's previous head, and on main at 823810a. 47a45fa is exactly those two commits merged.
• The other Bun versions on this head passed the same cell.

No fix to port. I'm re-running the failed job once. If it fails again, I'll treat it as real and dig in.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 47a45fa.

• CI: 403/403 non-skipped checks green (ci-ok success), 14 skipped
• Bugbot: reviewed 47a45fa, no unresolved findings.
• Mergeable: yes, no conflicts with base.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] The merge queue removed this PR after run 37834367420 failed. The only failed job is the Gradle e2e leg (e2e (ubuntu-latest, e2e_gradle_discovery_build …)), and it failed in the Install Gradle 6.9.4 step: downloading gradle-6.9.4-bin.zip from services.gradle.org, before any test ran. ci-ok failed only because that job failed. The other 211 jobs passed. This doesn't look like this PR's failure, and there's no code fix to make. The PR head (47a45fa) is still green and mergeable. It needs to be put back in the merge queue; I can't do that from here.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[final reviewer] Re-enqueued (auto-merge on, squash) at head 47a45fac. It was evicted at 20:12 UTC on the Gradle 6.9.4 install download failure noted above, before any test ran. This is the one re-queue.

---

Generated by Claude Code