Since node 8 and the introduction of util.promisify() many internal node modules have started using these two Symbols to provide hints to util.promisify() as to how the function should be promisified. However, only Symbol(util.promisify.custom) is readily available:
const customPromisifySymbol = require('util').promisify.custom
The second one Symbol(customPromisifyArgs) is a bit more difficult to get a reference to, but it can be done:
const customArgsSymbol = Object.getOwnPropertySymbols(require('fs').read)
.find((s) => String(s) === 'Symbol(customPromisifyArgs)')
Would it be possible to also expose a reference to the latter in a more convenient way, maybe as require('util').promisify.args? Is there a reason Symbol(customPromisifyArgs) isn't exposed the same way as Symbol(util.promisify.custom)?
From the discussion that landed util.promisify in core, we exposed the more generic custom symbol while hiding customPromisifyArgs because we wanted to gauge if/how much the latter could be helpful to userland, especially since the latter could be implemented in terms of the former. Plus, the semantics of Symbol(customPromisifyArgs) is not as clear and undebatable as Symbol(util.promisify.custom).
And...
const customArgsSymbol = Object.getOwnPropertySymbols(require('fs').read) .find((s) => String(s) === 'Symbol(customPromisifyArgs)')
Please don't use this in production code. Unexported things are not exported for a reason :)
Please don't use this in production code. Unexported things are not exported for a reason :)
Ha! You should've used an internal WeakMap if you didn't want users grabbing the symbols via reflection :feelsgood:
const internalPromisifyArgsMap = new WeakMap()
internalPromisifyArgsMap.set(require('fs').read, [ 'bytesRead', 'buffer' ])
Anyways, thanks that does make a lot of sense.
Most helpful comment
Ha! You should've used an internal WeakMap if you didn't want users grabbing the symbols via reflection :feelsgood:
Anyways, thanks that does make a lot of sense.