CRLF line endings are converted to LF line endings.

[hanxinwei]

Bug Report

Current Behavior
Use babel & gulp-babel in Windows 10.
The files with CRLF line endings will be transpiled to files with LF line endings, which in my view is not the expected behavior, since in Windows it's usually CRLF setting for git, and after the transpilation the git diff will show a lot of changes in output files caused by CRLF to LF changes, which is unexpcted.

Expected behavior/code
Keep the output CRLF/LF with source.

Environment

• Babel version(s): [e.g. 6.26.0]
• gulp-babel: [e.g. 7.0.1]
• Node/npm version: [e.g. Node v8.11.2/npm 5.6.0]
• OS: [Windows 10]

Possible Solution
Keep the output CRLF/LF with source.

[babel-bot]

Hey @hanxinwei! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[loganfsmyth]

Babel doesn't keep any whitespace information around after the file is parsed. In general we're reducing the amount of control over output formatting that we expose, because all we really want to guarantee is that the file we output will run properly, and CR/LF values don't affect that.

Assuming you're using autocrlf, I believe you can set a specific eol=lf value for the compiled assets: https://help.github.com/articles/dealing-with-line-endings/#per-repository-settings

[hanxinwei]

Thank you very much for your reply. @loganfsmyth
eol=lf seems to be an option.
This is kind of ... As a control freak in Windows every line ending should be CRLF. LOL. Thank you very much anyway.

[loganfsmyth]

I don't really know the specifics of how Git handles things. If we defaulted to CRLF instead, would people have the opposite problem? I could imagine if Git converts the CRLF to LF on checkout, and then the build outputs CRLF, it'd be a similar issue for people.

Since editors generally just support both anyway, it's not super clear to me how much there is to gain from going to CRLF route.

[hanxinwei]

I was kind of surprised when I googled and found no info regarding the babel line endings, since there must be the little gnawing problem if there exist collabrations between Mac and Windows. I can only assume most web developers are fans and users of Mac, which is true indeed in my work environment. Sometimes I feel a miracle using Windows with people around all using Mac. LOL.

Regarding CRLF/LF
https://stackoverflow.com/questions/10418975/how-to-change-line-ending-settings

We can guess the principle of Git is that let the users keep with the norm of OS ( CRLF in Windows, LF in Mac/Unix ), use one encoding in repo ( apparently the Git designers prefer and choose Unix's LF ), and provider the conversion betwen the disk files and repo.

[loganfsmyth]

I can only assume most web developers are fans and users of Mac,

There's certainly a large portion of Mac/Linux, but I think really you won't find much because people don't often commit their build output into Git in the first place. Usually I'd expect things to just be built and published to npm, but never tracked in Git.

[hanxinwei]

I can only assume most web developers are fans and users of Mac,

There's certainly a large portion of Mac/Linux, but I think really you won't find much because people don't often commit their build output into Git in the first place. Usually I'd expect things to just be built and published to npm, but never tracked in Git.

Oh yes, this is very likely the main reason. My project is kind of special that the compiled assets are intermediate products which are used as source by other projects and therefore tracked by Git. Surely this way is for compatibility, since not every project supports ES6/Babel.

[hanxinwei]

Actually I found something weirder is CRLF and LF both appear in the compiled file.
I didn't observe any rule regarding why some locations CRLF and the others LF.

[loganfsmyth]

We likely preserve CRLF in the output for literal tokens that contained newlines in the original source, like if you have CRLF in a comment or a template literal and don't transform them somehow, I think they would pass through with CRLF values still.

[hanxinwei]

We likely preserve CRLF in the output for literal tokens that contained newlines in the original source, like if you have CRLF in a comment or a template literal and don't transform them somehow, I think they would pass through with CRLF values still.

Got it. Thank you!

[catdad]

Not sure if this is the right place, but it was mentioned that line endings are correctly kept when they are part of the code itself, like template literals. I am finding that is not the case, and even in template literals, those endings are modified, which could result in a logical code change. Here is am example:

> babel.transform('var a = `\r\n`').code
'var a = `\n`;'
> babel.transform('var a = `\r`').code
'var a = `\n`;'
> babel.transform('var a = `\n`').code
'var a = `\n`;'

In this case, the code is trying to assign \r to a variable, but once transformed, it would be assigning \n to that variable. If I were to then use that variable in an if statement, my code would be logically different from the original source.

The code above uses babel-core 6.26.0, but I have also reproduced it with @babel/core 7.1.16.

[nicolo-ribaudo]

@catdad
It is expected: newlines in template literals are normalized to \n:

// Chrome console

> eval("`\r\n`")
"
"

> eval("`\r\n`").charCodeAt(0)
10

> eval("`\n`").charCodeAt(0)
10

> eval("`\r`").charCodeAt(0)
10

> "\n".charCodeAt(0)
10

If you don't want it, you should use actual \r or \n escape sequences:

`\r\n`;

which, when put inside a string, would become

babel.transform('var a = `\\r\\n`').code

Spec reference: https://tc39.github.io/ecma262/#sec-static-semantics-tv-and-trv (last bullet points)

[nicolo-ribaudo]

I'm closing this issue since maintaining the original code style is not a goal of Babel.