console.log and util.format formatting specifiers

[jsinmotion]

The Chromium console supports format specifiers: https://developers.google.com/web/tools/chrome-devtools/console/console-write#string_substitution_and_formatting

In particular, both %i and %d specify an integral argument. Node.js does not perform the conversion for %i:

/* node.js */
> console.log("%i", 1234)
%i 1234
/* google chrome */
> console.log("%i", 1234)
1234

I think the fix is really simple: the relevant code is at https://github.com/nodejs/node/blob/master/lib/util.js#L86-L117 . Just adding the i case should be enough:

      switch (f.charCodeAt(i + 1)) {
        case 105: // 'i' <-- this is the new line, and it should appear just before the `d` case to make the fall through work
        case 100: // 'd'

If it makes sense I can send a PR

[silverwind]

Not sure if aliasing %i to the current%d is a good idea. In all browsers that I've tested, those two convert to integer (while providing %f as a means to format floats). In node,%d serves a double purpose of supporting both float and integer.

%f behaviour is inconsistent between browsers. For console.log('%f', 1.5) Safari and Firefox print '1.500000' while Chrome does '1.5'.

I'd propose the following steps to fix:

• Make %d convert to integer and alias %i to it. This would be a breaking change.
• Introduce %f with once we're clear what to do about the 0 padding.

[Fishrock123]

As mentioned in #1716 (comment) we don't implement the console "spec" and honestly I don't think we are really about to. :/

We could do %f if it's reasonable I guess, honestly don't see much reason to not support %i in whatever way we think it should work either.

[jsinmotion]

I agree that there is no point in chasing a "spec" that doesn't exist, but this is a case where the major browser vendors agree!

As of 2016 Dec 15 this is the current conversion specifier support:

conversion	chrome	ie	firefox	node 6.9.1
%d	Integer	Integer	Integer	Number
%i	Integer	Integer	Integer
%s	String	String	String	String
%f	Float	Float	Float
%o	Object	Object	Object
%O	Object		Object
%b		Binary
%x		hex
%e		exp
%c	N/A
%j				JSON

IMHO nodejs should support %d %i %s %f %o in the same way that other browsers support the feature. The others, like IE's %x for hex, probably aren't critical.

This table is based on the following browser vendor resources:

• Chrome: https://developers.google.com/web/tools/chrome-devtools/console/console-write#string_substitution_and_formatting

• IE: https://msdn.microsoft.com/en-us/library/hh696634.aspx#Anchor_4

• Firefox: https://developer.mozilla.org/en-US/docs/Web/API/Console#Using_string_substitutions

EDIT: originally supported following browsers use of %o but that would be confusing since printf uses %o for octal integers.

[Fishrock123]

Well, there is definitely a "spec" but it's not really official to the language by any means: https://github.com/DeveloperToolsWG/console-object/

[jsinmotion]

The browsers actually do something wholly unexpected with the string conversions:

console.log("%s", {toString:function() { return "foo"; }})

My expectation is that "%s" would use the appropriate toString method, so that the output would be "foo". nodejs actually does what I would expect. Oddly, Chrome and Safari print "Object" rather than calling the object's toString.

Since I think node is actually doing the right thing here, I will close now and try to bring this discussion to the relevant browser vendors before revisiting in node

[silverwind]

Let's leave this open, there's certainly room for improvement on our side, and I like you nice table :)

[jsinmotion]

@silverwind The confounding factor related to the trailing digits in the floating format is support for the printf width and precision fields. Firefox has limited support but Chrome completely ignores those fields. If you want to see a difference in FF, try console.log('%.1f', 1.5) -- that should print 1.5 in FF. If I had to guess, chrome's behavior for %f is closest to the POSIX %.17g.

Since there are NPM modules like printj that fully replicate the POSIX printf spec, it seems fair to argue that node core should only support basic substitutions and people should fall back to userland code for heavy lifting.

@robertkowalski @terinjokes since you are mentioned in the whatwg spec, maybe you can chime in.