Generated files are in CRLF

[YoelDruxman]

Hello, I hope y'all are doing well!
I like to commit the generated files because then I immediately see if there is a change. The issue I am having is that the repo is in LF, but the generated files are in CRLF which results in a white-space change that shows up in git each time I build. Has anyone encountered this issue and what did you do to solve it?

Steps to reproduce

1. Commit generated file normalized to LF.
2. Regenerate the file

[YoelDruxman]

Proposal: Configurable Line Endings for Generated Source Files

Problem

On Windows, Mapperly outputs generated source files with CRLF (\r\n) line endings because Roslyn's APIs use Environment.NewLine. This causes issues for projects that enforce LF line endings via .gitattributes (* text=auto eol=lf), resulting in:

• Noisy git diffs
• CI failures on line ending checks
• Inconsistent formatting across team members on different OSes

Proposed Solution

Add a LineEnding configuration option to MapperAttribute that allows users to specify the desired line ending format for generated files.

---

Implementation

1. New File: src/Riok.Mapperly.Abstractions/LineEnding.cs

namespace Riok.Mapperly.Abstractions;

/// <summary>
///     Specifies the line ending format for generated source files.
/// </summary>
public enum LineEnding
{
    /// <summary>
    ///     Use platform default (Environment.NewLine).
    ///     This is the current behavior.
    /// </summary>
    Platform = 0,

    /// <summary>
    ///     Unix-style line feed (\n).
    ///     Recommended for cross-platform projects.
    /// </summary>
    Lf = 1,

    /// <summary>
    ///     Windows-style carriage return + line feed (\r\n).
    /// </summary>
    CrLf = 2
}

2. Modified: src/Riok.Mapperly.Abstractions/MapperAttribute.cs

Add property:

/// <summary>
///     Line ending format for generated source files.
///     Default: <see cref="LineEnding.Platform"/> (current behavior).
/// </summary>
public LineEnding LineEnding { get; set; } = LineEnding.Platform;

3. Modified: src/Riok.Mapperly/Configuration/MapperConfiguration.cs

Add property to read from attribute:

public LineEnding LineEnding { get; }

4. New File: src/Riok.Mapperly/Emit/LineEndingHelper.cs

namespace Riok.Mapperly.Emit;

internal static class LineEndingHelper
{
    /// <summary>
    ///     Normalizes line endings in the StringBuilder buffer before creating the final string.
    ///     Uses in-place replacement for efficiency (single allocation).
    /// </summary>
    public static string ToStringWithLineEnding(this StringBuilder sb, LineEnding lineEnding)
    {
        switch (lineEnding)
        {
            case LineEnding.Lf:
                sb.Replace("\r\n", "\n");
                break;
            case LineEnding.CrLf:
                sb.Replace("\r\n", "\n").Replace("\n", "\r\n");
                break;
            // Platform: no modification
        }

        return sb.ToString();
    }
}

5. Modified: src/Riok.Mapperly/Emit/SourceEmitter.cs

At the point where the source is built into a string, apply line ending normalization using the StringBuilder before calling ToString():

// Before:
var source = sb.ToString();
context.AddSource(fileName, SourceText.From(source, Encoding.UTF8));

// After:
var source = sb.ToStringWithLineEnding(configuration.LineEnding);
context.AddSource(fileName, SourceText.From(source, Encoding.UTF8));

This uses in-place StringBuilder.Replace() before creating the string, avoiding an extra allocation.

---

Files Changed Summary

File	Change
src/Riok.Mapperly.Abstractions/LineEnding.cs	New - Enum definition
src/Riok.Mapperly.Abstractions/MapperAttribute.cs	Add LineEnding property
src/Riok.Mapperly/Configuration/MapperConfiguration.cs	Read LineEnding from attribute
src/Riok.Mapperly/Emit/LineEndingHelper.cs	New - Helper extension method
src/Riok.Mapperly/Emit/SourceEmitter.cs	Apply line ending normalization at output

---

Usage

// Use LF for cross-platform compatibility
[Mapper(LineEnding = LineEnding.Lf)]
public partial class MyMapper { }

// Keep current behavior (platform default)
[Mapper]
public partial class MyMapper { }

---

Benefits

• Non-breaking: Default Platform preserves current behavior
• Efficient: Single allocation using StringBuilder.Replace() in-place
• Non-invasive: Only touches output point, no changes to generation logic
• User choice: Projects can opt-in to consistent LF or CRLF as needed

[latonz]

I’m not a fan of introducing a new configuration for this. It feels like a problem every source generator has to deal with. How do others handle this? Do they just use LF everywhere?
If we want to respect user preferences, I’d much rather rely on the EditorConfig option.

[YoelDruxman]

That is such a great point! Editor Config is a much better idea!
I am still new to source generators.

[YoelDruxman]

What is the process for formally submitting this as a proposal, or potentially opening a PR if it works?