Arguments parsed to numbers incorrectly.

[cowboy]

I know this is going to be a little bit subjective, but perhaps you can help.

It's hard to pass a version number to nopt like -r=1.10 because it will treat that value as the number 1.1 and not the string "1.10". This can be worked around by prefixing it like -r=v1.10 but it's inconvenient to have to strip out the leading v in that case if you don't need it.

Would it be possible for nopt to check to see if the value, once converted to a number and then back to a string matches the original string, Eg.

function getNumberOrString(str) {
  var num = Number(str);
  // Only return number if a) it's a valid number, and b) when coerced
  // back to a string, that string is the same as the original string.
  return !isNaN(num) && String(num) === str ? num : str;
}

getNumberOrString("1.23") // 1.23
getNumberOrString("1.10") // "1.10"
getNumberOrString("01234") // "01234"

What nopt currently does is something more like this:

function getNumberOrString(str) {
  var num = Number(str);
  // Only return number if it's a valid number.
  return !isNaN(num) ? num : str;
}

getNumberOrString("1.23") // 1.23
getNumberOrString("1.10") // 1.1
getNumberOrString("01234") // 1234

Here's an example of this "bug" in action:

$ npm install nopt@latest
npm WARN package.json foo@0.0.0 No README.md file found!
npm http GET https://registry.npmjs.org/nopt
npm http 304 https://registry.npmjs.org/nopt
npm http GET https://registry.npmjs.org/abbrev
npm http 304 https://registry.npmjs.org/abbrev
nopt@2.1.2 node_modules/nopt
└── abbrev@1.0.4

$ node -pe "require('nopt')({}, {}, ['-a=1.23', '-b=1.10', '-c=01234'], 0)"
{ a: 1.23,
  b: 1.1,
  c: 1234,
  argv:
   { remain: [],
     cooked: [ '-a', '1.23', '-b', '1.10', '-c', '01234' ],
     original: [ '-a=1.23', '-b=1.10', '-c=01234' ] } }

[cowboy]

FWIW, jQuery did something like this at one point trying to make their data- attribute parsing smart and it ended up being a bit of a mess.

[michaelficarra]

Just specify it to be a string by providing knownOpts. Your proposed behaviour would not be desirable for me since I often use scientific notation to specify numeric values (e.g. -n 1e6).

[cowboy]

@michaelficarra In this case, these are unexpected arguments.

[cowboy]

If unexpected were always stored as strings (maybe an option could be added to enable this) then it could be up to the end-user how they wanted to coerce or parse that string value. Which would solve both problems, I think.

[michaelficarra]

Yes, I could agree with that.

[cowboy]

This is how I'd do it. Create an option whereby a "reviver" method (like JSON.parse has) can be specified for unknown values, with the default being the current behavior. Then, if I want every unknown value to be a string, the reviver method I'd specify is function(s) { return s; }.

[isaacs]

I could see adding a type that preserves trailing/leading zeroes like you describe. It shoudln't be too hard to do in your app with a custom type, but you'll probably have to look at the nopt and/or npm source to see how to go about it. Doc patch welcome.

[cowboy]

I'm talking about unexpected arguments.

[isaacs]

Oh, right. Sure, patch welcome.

[michaelficarra]

(maybe an option could be added to enable this)

Please, no additional options. Just unconditionally treat unexpected values as strings.