Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

An option for line endings, don't enforce it #20

darsain opened this Issue Mar 24, 2013 · 5 comments


None yet
6 participants

darsain commented Mar 24, 2013

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?

The default should be empty instead of a new line.


stevenbenner commented Mar 27, 2013

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 shama closed this in 2da5f3d Apr 8, 2013


shama commented Apr 8, 2013

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

levacic commented Apr 2, 2014

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?


jmeas commented Apr 2, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment