How to access placeholder tokens?

[niftylettuce]

Is there a simple way to return an array of tokens used as placeholder tokens (e.g. for util.format)?

https://nodejs.org/api/util.html#util_util_format_format_args

e.g. ['%s', '%d', '%i', ...]

[Trott]

I'm unaware of any way to do this programatically. What's the use case? If the use case is persuasive, then a request to add the feature would be likewise persuasive.

[niftylettuce]

@Trott thank you for the quick reply. I've provided insight and references for the use case below.

I wrote my own log utility (see https://github.com/ladjs/logger) and want to support developers that might be using console.log in a way that uses placeholder tokens, e.g. console.log('hello world', { foo: 'bar' }, '%s', 'some text'); or console.log({ some: 'object' }, 'hello there %o', { hello: 'world' }) - in short design a drop-in replacement for util.format, console.log, and util.log.

I discovered the issue and realization that not everyone uses a logger the same way. Some people might use console.log and pass it a dozen arguments... while others might adhere to a strict two or three argument approach (some even with specific variable types for each argument).

In my logger package, the first argument should be a string, the second an object. At first I thought this was OK, but I want to support packages that might not adhere to this approach and not throw errors (which is bad design anyways - and I've removed it from the latest release of my package). See cabinjs/axe#6.

I've currently just created an array of tokens that I use (see https://github.com/ladjs/logger/blob/master/index.js#L39-L45)... and I was going to publish this as a package, e.g. placeholder-tokens. However I feel that this should be stored in the util package itself, and accessible through a property such as util.placeholderTokens or util.tokens for short (outputs the same Array basically).

Having it in in the core util package would be better as its core in itself, and I'd rather not have people with the same use case be using some random and possibly unmaintained npm package.

[Trott]

One argument for including in core is that we add placeholders from time to time (and could remove some too) so a userland package could provide the correct values for one version of Node.js but wrong values for another version.

It seems like this should be achievable with little or no performance overhead.

Deciding on a name might involve some bike-shedding, but that's OK. (In what is sure to be an unpopular suggestion, I was wondering if made sense to make it a property hung of util.format itself, so util.format.placeholders or something like that.)

@nodejs/collaborators: Thoughts on whether or not this feature should be implemented? And, if it gets implemented, thoughts on a name?

@niftylettuce If you want to submit a pull request adding this functionality, having actual code to review might speed things along ultimately. (Just be prepared to make changes because people will have suggestions.)

[cjihrig]

thoughts on a name?

format specifiers

[Trott]

util.format.specifiers? :-D

[niftylettuce]

vote?

[benjamingr]

Honestly this doesn't look like it's too hard to keep track of in userland - and it's one more thing we have to maintain.

I'm +0 on this leaning to -1 but no strong feelings.

[mcollina]

I'm +1. If we can keep these in sync easily, then we should definitely do it. If we have to duplicate code, then its better we do it here anyway.

[TimothyGu]

I'm fine with it only if the array is Object.freeze()'d.

[addaleax]

@TimothyGu huh? not objecting, but why?

[TimothyGu]

@addaleax I don't want people to be able to modify the array in any way. People who override util.format will replace this array which is attached to the formatting function anyway.

[bnoordhuis]

I don't see the point. Knowing what placeholders node.js knows about tells you nothing about how it interprets them. The only reasonable thing to do is call util.format.apply(util, args).

[mcollina]

I don't see the point. Knowing what placeholders node.js knows about tells you nothing about how it interprets them. The only reasonable thing to do is call util.format.apply(util, args).

I disagree. It is useful if you want to escape them.