GeezerVison

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

Fixes #1831

Summary

scan --mode hosted / get --mode hosted over a CRLF Gemfile (a Windows checkout, or core.autocrlf=true) wrote the Socket source "…" do … end block with bare LF endings, so the committed Gemfile ended up with mixed line endings. Now:

• In-place rewrite of a gem line (plain, with options, parenthesized, inside the user's own source … do block): the block takes the ending of the line it replaces. The line's CR goes back at the end of the block, not inside it. An unterminated last line takes the file's ending, and a lone trailing CR at EOF is no longer read as a line ending.
• Appended block for a transitive gem: takes the file's ending (line_endings::terminator, so the majority wins on a mixed file), for both the separator and the block.
• Rollback / remove (upstream/gem.rs restore_manifest) now restores the declaration with the block's own ending. Before, it used CRLF whenever the file held any CRLF line. An LF block (the only spelling written before this PR) takes the ending of the lines around it, so existing redirected projects restore the same as before.

This is the hosted-mode twin of #1821 / #1822 (vendored mode).

Root cause

rewrite_gem in crates/socket-patch-core/src/patch/redirect/mod.rs built the block from a literal with hard-coded \n in both arms (in-place and append). The in-place arm's gem_line_re match also ran up to the line's CR, so the CR was dropped and the block ended in the original line's bare LF.

The recognizers already accept \r?\n: the re-run idempotency guard, gem_spelling_residue, the restore's socket_blocks, and VEX's parse_source_blocks (via str::lines). So a CRLF block is recognized everywhere, and the e2e test below confirms that against real bundler.

No wrapper changes: npm/, pypi/ and gem/ only dispatch to the binary.

Tests (red → green)

One existing test changed its expectation: gemfile_single_line_declaration_lookalikes_still_rewrite has a CRLF declaration in an LF file (gem "vuln-gem", require: false\r). It pinned the old LF block and now expects that line's CRLF. That is the intended rule: the block takes the ending of the line it replaces.

Commands run locally:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --lib: 6992 passed, 4 failed. All 4 are the known permission-denial tests that can't fail a write as root in this sandbox (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_…, pypi_requirements::wire_failure_rolls_back_…). None touch gem code.
• cargo test -p socket-patch-cli --all-features --test e2e_redirect_gem_build --test e2e_vendor_gem_build (--ignored): 38 + 11 passed. Without --ignored: 21 + 35 passed.
• I couldn't finish the full cargo test --workspace --all-features: the sandbox ran out of disk while linking the CLI test binaries. CI is the full-suite gate.

Per-issue checklist

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 single-line declaration, CRLF Gemfile with LF or CRLF lock: gemfile_source_block_keeps_crlf_line_endings, gem_hosted_redirect_keeps_a_crlf_gemfile_crlf (crlf-gemfile)
• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 declaration inside a user source … do block: same unit test, and e2e (crlf-gemfile-source-block)
• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 append arm (transitive gem): gemfile_source_block_keeps_crlf_line_endings (puma → rails cases)
• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 converging install, re-scan no-op, rollback in CRLF: gem_hosted_redirect_keeps_a_crlf_gemfile_crlf

/code-review high

Fixed:

• Rollback chose its ending by "any CRLF in the file" while the forward pass now keeps the replaced line's ending. Rollback now follows the block's own ending.
• The recorded FileEdit.new left out the CR that was actually written. It now records the exact spliced text.
• A lone trailing CR at EOF was treated as a CRLF ending and left a stray CR. Now covered by a test.
• Stale "the rewriter emits LF" comments are updated, and the unit test uses LineEndings::of instead of a hand-rolled counter.

Not changed:

• Excluding the CR in gem_line_re itself instead of stripping it after the match. That is equivalent, and keeping the regex unchanged leaves the swallowed-whitespace behaviour that rollback depends on (Gem hosted rollback / remove turn a redirected transitive gem into a top-level exact pin, because the restore looks for a blank line the rewriter never writes #457) untouched.
• On a mixed-ending file, rollback can't tell an LF block written before this PR apart from one written for an LF line, so it uses the ending of the surrounding lines. That's the same as main for every pre-existing project.

https://claude.ai/code/session_011f9aeRvMuTRkgqjmDvPu3j

Generated by Claude Code