Most CLI options not working

[brlodi]

I initially discovered that passing --time-format on the CLI has no effect, and further exploration has shown that there's kind of a mess going on all around.

Things I've found turning on debug output:

• --newline, --time-format, and --property-map are not applied to resolved configuration, so they don't actually do anything
• The short form -n is interpreted as --noColor instead of --newline, though using --newline correctly populates the short alias -n
• --color and --no-color seem to work
• Configuration via config file works fine, and the debug-printed config matches it + defaults

My suspicion is that the arguments and file config are being merged backwards, i.e. command line args are being overwritten by the already-combined config file + defaults map, so any arguments are just obliterated. That would explain why the color options still work, since they don't appear in the default config.

With long form arguments:

Note the correct options are logged, but the resolved config is just the default.

node src/index.js | DEBUG=* pino-dev --time-format HH:mm:ss --newline "\r\n" --property-map '{ "foo": "msg" }'
  pino-dev pino-dev started with options: {
  pino-dev   "t": "HH:mm:ss",
  pino-dev   "timeFormat": "HH:mm:ss",
  pino-dev   "n": "\\r\\n",
  pino-dev   "newline": "\\r\\n",
  pino-dev   "m": "{ \"foo\": \"msg\" }",
  pino-dev   "propertyMap": "{ \"foo\": \"msg\" }"
  pino-dev } +0ms
  pino-dev Using config {
  pino-dev   "newline": "\n",
  pino-dev   "timeFormat": "HH:mm:ss.SSS",
  pino-dev   "propertyMap": {
  pino-dev     "msg": "msg",
  pino-dev     "level": "level",
  pino-dev     "ns": "ns",
  pino-dev     "name": "name",
  pino-dev     "stack": "stack",
  pino-dev     "time": "time",
  pino-dev     "req.method": "req.method",
  pino-dev     "req.url": "req.url",
  pino-dev     "res.statusCode": "res.statusCode",
  pino-dev     "responseTime": "responseTime"
  pino-dev   }
  pino-dev }. +2ms

With short form arguments

Note that the -n is being picked up as noColor instead of newline. I'm guessing the args package implicitly creates short aliases by default, so since no-color is defined first it "steals" the result of parsing -n.

$ node src/index.js | DEBUG=* pino-dev -t HH:mm:ss -n "\r\n" -m '{ "foo": "msg" }'
  pino-dev pino-dev started with options: {
  pino-dev   "t": "HH:mm:ss",
  pino-dev   "timeFormat": "HH:mm:ss",
  pino-dev   "n": "\\r\\n",
  pino-dev   "noColor": "\\r\\n",
  pino-dev   "m": "{ \"foo\": \"msg\" }",
  pino-dev   "propertyMap": "{ \"foo\": \"msg\" }"
  pino-dev } +0ms
  pino-dev Using config {
  pino-dev   "newline": "\n",
  pino-dev   "timeFormat": "HH:mm:ss.SSS",
  pino-dev   "propertyMap": {
  pino-dev     "msg": "msg",
  pino-dev     "level": "level",
  pino-dev     "ns": "ns",
  pino-dev     "name": "name",
  pino-dev     "stack": "stack",
  pino-dev     "time": "time",
  pino-dev     "req.method": "req.method",
  pino-dev     "req.url": "req.url",
  pino-dev     "res.statusCode": "res.statusCode",
  pino-dev     "responseTime": "responseTime"
  pino-dev   }
  pino-dev }. +2ms

[dnjstrom]

Hi @brlodi, thank you for taking the time to investigate and report the issue(s)! There does indeed seem to be something strange going on with the argument handling, I'll poke around and see if I can figure out what's going on. 👍

[dnjstrom]

Like you suspected @brlodi, the command line arguments were not being merged properly with the other configuration methods and the single character flag for newline was overridden by the no-color flag. I believe both issues were addressed in #2 and I've published a new version of the package 1.0.5 with the changes. Please give it a spin and let me know if it seems to work for you 👍

Unrelated to the issues above, I also noticed you've inverted the property-map object definition in your examples. The key should be the semantic property name, and the value the incoming property name, i.e. --property-map '{ "msg": "foo" }'. Currently, the incorrect mapping will simply be ignored, but it'd probably make better sense to throw an error instead in the future.

Please let me know if you have any further issues and thank you again for the detailed issue description - much appreciated!

[brlodi]

Thanks for tackling this so quickly! It seems like everything is working as expected with 1.0.5.

And thank you for pointing out the mapping. I definitely had the real version of it backwards in my package.json and would have been very much confused.