Feature request: Configurable New-Line/End-of_line characters

[jens-duttke]

The End-Of-Line characters used in newly created d.ts files always depends on the system setting. That means it differs between Unix/Linux/Mac (LF) and Windows (CRLF).

I'm working in projects where LF is forced and an ESLint rule ensures the correct EOL characters.
The result is, for every new d.ts file created by this loader on Windows, I have to manually switch the EOL characters manually.

Git fixes that automatically using the .gitattributes, but that requires that I first commit my changes to get the correct line endings.
Another hack I found, was to place this at the beginning of my webpack.config.js:

// Force Unix line endings
Object.defineProperty(require('os'), 'EOL', {
	value: '\n',
	writable: false
});

But instead of using hacks or relying on third-party software, it would be nice if this plugin could use the correct EOL characters by itself.
I could imagine atleast 3 ways how to do that:

• Use the setting in the .editorconfig
• Use the same line-ending as the TypeScript file (where the Sass file is imported), or the line-ending of the Sass file.
• Provide an option which allows to configure the line-ending the user prefers.

TypeScript provides in the tsconfig.json also an option newLine to configure the line-ending, but that's for the generated JavaScript file, not for the TypeScript code - since this can differ, it shouldn't be considered here.

What do you think?

[c0gnize]

I think that the detecting line ending by using require('os') may be insufficient. For example some my repository placed under Window and using crlf, but sometimes I editing it through WSL (Unix).

Therefore, it is necessary to regulate line endings manually. And since .editorconfig is the most widely used, it will be the best choice.

[c0gnize]

@jens-duttke, what do you think to solve the current problem with customtypings?

[jens-duttke]

@jens-duttke, what do you think to solve the current problem with customtypings?

@c0gnize: For my usecase this workaround fixed the problem.