An option for line endings, don't enforce it

[darsain]

I use exclusively LF line endings in all of my files. However I develop on Windows, so grunt concat always joins the files with CRLF, even if they are all LF.

Can there be either an option to choose which line endings I want, or perhaps concat could detect line endings in src files and use that?

[FagnerMartinsBrack]

The default should be empty instead of a new line.

[stevenbenner]

In your Gruntfile.js add the following line:

grunt.util.linefeed = '\n';

That will override the default (environment based) line endings for all tasks that use the grunt configuration to determine what line endings to use.

[shama]

The separator is no longer normalized allowing you to set LF on a Windows environment. Published as 0.2.0.

[levacic]

We're having trouble with this on Windows.

Using (as of 2014-04-02) latest versions of everything:

• node 0.10.26
• grunt-cli 0.1.13
• grunt 0.4.4
• grunt-contrib-concat 0.4.0

Some debugging has shown that options.separator, when set to \n\n already gets normalized before it reaches grunt-contrib-concat, so it might not be this plugin's issue, but we're not sure.

We've debugged it by using the stringToBytes function found here: http://stackoverflow.com/questions/1240408/reading-bytes-from-a-javascript-string - we've added grunt.log.writeln('Separator: ' + stringToBytes(options.separator)); just after the }).join(options.separator) + footer; line in concat.js, and we get Separator: 13,10,13,10 on the command line.

As far as we can tell, the problem is the call-chain config.get -> config.process -> template.process -> util.normalizelf, so configuring separator: "\n\n" makes options.separator become 0d0a0d0a within the concat task - is this something that can be solved within this plugin, or should we file an issue with the main grunt repo?

[jamesplease]

the problem is the call-chain

@levacic! Very impressive sleuthing. That is what's causing this to happen. We ran into a very similar problem recently on Uglify. I think this might be worthwhile to bring up on the main Grunt repo. I think it's undesirable that we normalize the line feeds of the options since we process them all as templates.