[Performance] Optimize detectEOL utility function

[gonzaloriestra]

WHY are these changes introduced?

The original detectEOL implementation in packages/cli-kit/src/public/node/fs.ts iterated over the regex match array twice (once per .filter() call) and allocated two intermediate arrays just to count \r\n and \n occurrences. For inputs with many line endings this is wasteful in both time and memory.

WHAT is this pull request doing?

• Replaces the two .filter() passes in detectEOL with a single for...of loop that counts \r\n once and derives the \n count by subtraction.
• Adds a short comment explaining why the loop is preferred.
• Behavior and return values are unchanged; existing fs.test.ts cases continue to cover the function.

How to test your changes?

detectEOL is consumed inside cli-kit by addToGitIgnore, and there is no end-user CLI command in this repo that calls it directly today (downstream consumers reach it via that helper). The most direct manual check is to invoke the function via the built module and confirm the same output as before for inputs that mix line endings. Run from the repo root:

pnpm install
pnpm nx build cli-kit

node -e "import('./packages/cli-kit/dist/public/node/fs.js').then(({detectEOL}) => {
  console.log(JSON.stringify(detectEOL('a\r\nb\r\nc\r\n')));   // expect: \"\\r\\n\"
  console.log(JSON.stringify(detectEOL('a\nb\nc\n')));         // expect: \"\\n\"
  console.log(JSON.stringify(detectEOL('a\r\nb\nc\r\n')));    // expect: \"\\r\\n\" (more CRLF than LF)
  console.log(JSON.stringify(detectEOL('no-newlines')));        // expect: platform default (\"\\n\" on macOS/Linux)
})"

(Optional) Quick sanity benchmark to confirm the speedup on large inputs:

node -e "import('./packages/cli-kit/dist/public/node/fs.js').then(({detectEOL}) => {
  const big = ('line\r\n'.repeat(100_000)) + ('line\n'.repeat(100_000));
  const t = process.hrtime.bigint();
  for (let i = 0; i < 50; i++) detectEOL(big);
  console.log('avg ms:', Number(process.hrtime.bigint() - t) / 1e6 / 50);
})"

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing — I've identified the correct bump type (patch for bug fixes · minor for new features · major for breaking changes) and added a changeset with pnpm changeset add

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[gonzaloriestra]

Merge activity

• Apr 30, 1:54 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Apr 30, 1:54 PM UTC: @gonzaloriestra added this pull request to the GitHub merge queue with Graphite.