fix(android,flutter): Preserve CRLF line endings when present

[andreiborza]

This PR fixes mixed line endinges when the wizard modifies files that have CRLF (\r\n) line endings. Previously we would always append LF (\n), thus mixing line endings, causing issues on platforms that use CRLF.

It adds a fixLineEndings() post-processing step for Android and Flutter wizards that detects modified files with CRLF and normalizes any LF to CRLF.

Other wizards use proper formatters or don't suffer from this issue.

Closes: #1249

[github-actions]

Semver Impact of This PR

🟢 Patch (bug fixes)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

Bug Fixes

• (android,flutter) Preserve CRLF line endings when present by andreiborza in #1253

Internal Changes

• (agents) Convert commands to dotagents skills by chargome in #1236
• Pin GitHub Actions to full-length commit SHAs by joshuarli in #1244

---

_{🤖 This preview updates automatically when you update the PR.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Flutter wizard fixes line endings before MCP writes files
  • Moved fixLineEndings() call to after offerProjectScopedMcpConfig() to match the Android wizard pattern and ensure all modified files are processed.

Or push these changes by commenting:

@cursor push 29226be55e

Preview (29226be55e)

diff --git a/src/flutter/flutter-wizard.ts b/src/flutter/flutter-wizard.ts
--- a/src/flutter/flutter-wizard.ts
+++ b/src/flutter/flutter-wizard.ts
@@ -161,9 +161,6 @@
   }
   Sentry.setTag('main-patched', mainPatched);
 
-  // Fix mixed line endings caused by inserting LF content into CRLF files (Windows)
-  fixLineEndings();
-
   // ======== OUTRO ========
 
   // Offer optional project-scoped MCP config for Sentry with org and project scope
@@ -172,6 +169,9 @@
     selectedProject.slug,
   );
 
+  // Fix mixed line endings caused by inserting LF content into CRLF files (Windows)
+  fixLineEndings();
+
   const issuesPageLink = selfHosted
     ? `${sentryUrl}organizations/${selectedProject.organization.slug}/issues/?project=${selectedProject.id}`
     : `https://${selectedProject.organization.slug}.sentry.io/issues/?project=${selectedProject.id}`;

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

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

[JPeer264]

LGTM

Tests are failing though

[Lms24]

naive question: If the LF endings only come from the files our wizard touches, could we use os.EOL to use the correct line breaks in the code modifications directly? Wondering if this isn't better than the post processing step but if there's a good reason for it, then no objections :)

[andreiborza]

@Lms24 I was initially thinking of going that route but it seemed less safe to me, what if the environment that runs the wizard is not the same as the environment that runs the app?

A post-processing step seemed more in line with what we do with the js wizards with prettier.

[sentry]

Bug: The new fixLineEndings function relies on a utility that incorrectly parses file paths with spaces, causing those files to be silently skipped during line ending normalization.
_{Severity: MEDIUM}

Suggested Fix

Modify getUncommittedOrUntrackedFiles to correctly parse filenames with spaces. The recommended approach is to use git status --porcelain -z, which provides NUL-terminated output, making parsing unambiguous and robust.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/utils/line-endings.ts#L29

Potential issue: The `getUncommittedOrUntrackedFiles` function parses `git status`
output by splitting on whitespace. This causes it to incorrectly handle filenames that
contain spaces, truncating the path. The new `fixLineEndings` function calls this
pre-existing utility. As a result, any uncommitted files with spaces in their names will
be silently skipped during the line-ending normalization process, leading to an
incomplete fix for users on Windows environments where this is common.

[Lms24]

Good point, thanks for explaining!