feat: define custom promisify implementations #45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@microsoft-github-policy-service agree |
Tyriar
requested changes
Nov 9, 2022
This defines properties on each of the exported asynchronous functions which allow them to work with Node's `promisify`. The existing callbacks were incompatible by default, because they: • are not given as the last arguments of those functions • do not accept optional "error" as their first arguments In other words, they are not "Node-style". This implementation chooses to reject promises rather than returning `undefined` on those errors, as the callbacks do: presumably the `undefined` value is used simply because the existing callback format forgot to allow for an error parameter. This defines both the modern `promisify.custom` symbol and the "old" `__promisify__` property, since the former isn't actually describable in TypeScript definitions yet, and the latter is still used in Node's definition files (e.g. for `child_process` functions). See: • microsoft/TypeScript#36813 • DefinitelyTyped/DefinitelyTyped#42154
This adds the module 'windows-process-tree/promises', exposing the
promisified variants of the primary library methods.
It would be nice to also make this a property on the
'windows-process-tree' index module, but with the current structure that
requires some work to avoid a mutually-recursive import.
Since the `index.ts` file sets the [promisify.custom]/__promisify__
properties at the top level, and the './promises' module uses those at
the top level to expose the promisified implementations, there's an
initialization mutual dependency.
The simplest thing, done here, is to only support explicit importing of
`windows-process-tree/promises`.
To do it properly, either:
• one of `index.ts` or `promises.ts` exposes lazy-init'd properties
via a `defineProperty` getter on `exports`
• or, simplest but noisiest, move the current `index.ts` to
something like `_core.ts`, and create an `index.ts` with:
export * from './_core';
export * as promises from './promises';
However that doesn't don't seem worth immediate testing effort, and can
always be done later without breaking API compatibility.
Tyriar
approved these changes
Nov 10, 2022
rzhao271
approved these changes
Nov 10, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This defines properties on each of the exported asynchronous functions which allow them to work with Node's
promisify.The existing callbacks were incompatible by default, because they:
In other words, they are not "Node-style" callbacks.
This implementation chooses to reject promises rather than returning
undefinedon those errors as the callbacks do: presumably theundefinedvalue is used simply because the existing callback format forgot to allow for an error parameter.This defines both the modern
promisify.customsymbol and the "old"__promisify__property, since the former isn't actually describable in TypeScript definitions yet, and the latter is still used in Node's definition files (e.g. forchild_processfunctions). See:CustomPromisifyDefinitelyTyped/DefinitelyTyped#42154Example usage: