[bartlomieju]

Summary

Implements the Node.js v8.promiseHooks API — onInit, onBefore, onAfter, onSettled, and createHook — on top of Deno core's existing core.setPromiseHooks V8 bindings.

This is the clean, self-contained half of #32905, carved out and reimplemented against current main (the original PR was based on a since-rewritten v8.ts and process.ts). The --unhandled-rejections half will follow separately, rebuilt on top of the current synchronizeListeners.

Implementation notes

• Validation: rejects non-functions, async functions, and async generators, matching Node's error message (The "<name>" argument must be of type function).
• Re-entrancy guard: V8 promise hooks fire for all promise operations, including promises created inside the hooks themselves — a flag prevents infinite recursion.
• Single-registration dispatcher: core.setPromiseHooks is additive-only (no removal), so we install permanent dispatchers once that consult the current hook arrays. The stop function returned by each registration splices the hook back out.

Tests

Enables two node_compat tests, both passing:

• parallel/test-promise-hook-on-init.js
• parallel/test-promise-hook-on-before.js

The remaining hook tests (on-after, on-resolve, create-hook) are left disabled: they assert exact hook-invocation counts that Deno's internal runtime promises perturb, and need further work to reconcile.

Test plan

• cargo test -p node_compat_tests test-promise-hook-on-init — passes
• cargo test -p node_compat_tests test-promise-hook-on-before — passes
• ./tools/format.js && ./tools/lint.js --js clean

🤖 Generated with Claude Code

[bartlomieju]

Reviewed the promiseHooks implementation — the core mechanism is sound (correct setPromiseHooks(init, before, after, resolve) arg order, the settled → resolve mapping is right, the length-guarded permanent dispatchers keep the never-uninstalled hooks cheap, and the global inPromiseHook re-entrancy guard is fine since cross-type events only fire via microtasks after it resets). Two issues on the mutation/removal paths worth addressing:

1. A hook that removes itself mid-dispatch skips a sibling hook.

The dispatcher loops re-read .length each iteration and iterate the live array while removeHook splices it in place:

for (let i = 0; i < initHooks.length; i++) {
  initHooks[i](promise, parent);
}

Register init hooks A and B, and have A's body call its own stop(). On an init event: i=0 calls A → A splices index 0 → array becomes [B] (length 1) → i=1, 1 < 1 is false → loop ends and B never fires for that promise, even though it's a live registered hook. Node snapshots the hook list before invoking to avoid this. Fix: iterate over a copy, e.g. ArrayPrototypeSlice(initHooks, 0).

2. createHook leaks partially-registered hooks when a later callback fails validation.

createHook validates-and-pushes init, then before, etc. sequentially:

createHook({ init: goodFn, before: 123 })

pushes goodFn into initHooks, then throws on before's validatePlainFunction. goodFn is now permanently registered (fires on every promise init) and no stop function is returned to remove it. Fix: validate all provided callbacks up front, before any ArrayPrototypePush — matching the validate-then-mutate order the single-hook setters already use. (Node may share this latent behavior via its per-setter registration, so it's partly a parity call, but it's cheap to prevent here.)

Everything else checked out: double-calling a returned stop() is harmless (indexOf returns -1), and primordials usage is consistent with the rest of the file.

[bartlomieju]

Thanks for the review — both addressed in cc6add4:

1. Self-removing hook skipping a sibling. The four dispatchers now snapshot the hook list (ArrayPrototypeSlice(hooks, 0)) before iterating, so a hook that calls its own stop() (or removes another) mid-dispatch no longer shifts indices out from under the remaining hooks. Verified: with init hooks A and B where A stops itself, both A and B fire on the same promise.

2. createHook leaking partially-registered hooks. It now validates every provided callback first, then pushes them — so createHook({ init: goodFn, before: 123 }) throws without registering goodFn. Verified: after the throw, the init hook count stays 0.

test-promise-hook-on-init.js / -on-before.js still pass.