Interpreting grunt Command-Line Option as a String

Question

As part of the build process, we run the Grunt task as follows:

grunt release -r 3.9 

The release number passed with the -r option is used to tag various parts of the release.

The problem occurs with releases ending in zero - for example, 3.10. Grunt treats this as a number, omits the trailing zero, and thinks it is release 3.1.

Here is a simple Grunt file that demonstrates the problem:

 module.exports = function(grunt) { grunt.registerTask('default', 'Release preparation', function () { var rel = grunt.option("r").toString(); grunt.log.writeln("Release data type:" + typeof rel); grunt.log.writeln("release (" + rel + ")"); }); }; 

Here is what you get:

 $ grunt -r 3.10 Running "default" task Release data type:string release (3.1) Done, without errors. 

toString() converts it to a string accordingly, but the damage has already been done. The final zero is gone.

How to get around this?

Answer 1

Unfortunately, this seems to be a design behavior, since grunt-cli uses the nopt module to do parsing on the command line. See code here , key line:

 return nopt(exports.known, exports.aliases, process.argv, 2); 

This is what nopt has to say about types (my attention):

When parsing unknown fields, true, false, and null will be interpreted as their JavaScript equivalents, and numeric values ​​will be interpreted as a number.

A couple of workarounds could be:

• Use something like grunt release -r "v3.10" on the command line and cancel the "v" in your grunt code
• Read process.argv again in your grunt code and pass it to the parameter parser of your choice.