Should the extension change line feeds on compilation?

[ColinBroughNHS]

Ensemble 2018.1 instances, doing client side development on Windows systems, with BitBucket Cloud as shared repo.
Git has core.autocrlf set to true, so when pulled a file modified by another developer appears locally with CRLF line endings.

After compilation via the extension the file has LF line endings (otherwise not modified). "Import" on its own does not impact the line ending, only compilation.

Is this expected behaviour?
We are heading down the .gitattributes / force ObjectScript .cls files to be treated as having LF line endings only / moving away from core.autocrlf set to true - is there anything else we could / should change?

Thanks! Colin

[gjsjohnmurray]

What platform are your Ensemble 2018.1 instances running on?

[ColinBroughNHS]

Local development: Windows 10 Enterprise, version 22H2. Each developer is running VS Code on their laptop, where the Ensemble 2018.1 is also running.

(We also have an integration/development instance, a UAT instance and a production instance; those are running on Windows Server 2019 Datacenter. But we rarely use those against VS Code, so we haven't observed the behaviour there - might be same, but we haven't checked.)

[isc-bsaviano]

The Atelier API that our extensions use to talk to the server works with documents as an array of lines, so there are no line separators. When building an array of lines to send to the server, our extensions are tolerant of both CRLF and LF. However, when receiving a file from the server and showing it in VS Code (or writing to a file system) we always use LF. I think your .gitattributes approach is the right approach to keep things normalized in your source control repository. I will open a request to get this added to our documentation.

[ColinBroughNHS]

Thanks, that's really helpful. And we've no idea why BitBucket Cloud shows this up when our previous repo (GitLab locally hosted) didn't.