why-is-node-running is pinned to ^2.3.0, which keeps stackback@0.0.2 (2012, archived upstream) in every dependency tree

Hi, and thanks for Vitest.

While auditing third-party licences across our repositories, stackback@0.0.2 was the one component we could not close documentarily. Tracing it led here, and the situation looks resolvable now in a way it was not when it was last considered.

The chain

vitest → why-is-node-running ^2.3.0 → stackback 0.0.2  (+ siginfo ^2.0.0)

Declared in packages/vitest/package.json; used in packages/vitest/src/node/reporters/hanging-process.ts.

why-is-node-running@3.2.0 dropped both transitive dependencies — 3.2.0 and later declare "dependencies": {}. (Worth noting since it is easy to assume v3.0.0 did it: 3.0.0 and 3.1.0 still carried siginfo and stackback.)

Why stackback specifically is awkward downstream

• Last published 2012-10-20; only two versions ever exist (0.0.1, 0.0.2).
• Its repository, shtylman/node-stackback → defunctzombie/node-stackback, is archived, last pushed 2013-10-16. Archived repositories do not accept issues, so there is no upstream to ask for anything.
• It declares "license": "MIT" in package.json but ships no licence text — not in the tarball, not at tag v0.0.2 (commit 2963095372abf7b75ba55f01cef08ab1e62c2ff4). Compliance tooling therefore reports it as undetermined, and there is no copyright holder to attribute.

None of that is a security problem — there are no advisories and the package is not deprecated. It is a licence-provenance dead end, and it is inherited rather than chosen.

Why this looks feasible now, and was not in 2024

#6128 (Renovate, ^2.2.2 → ^3.2.0) was closed on 2024-07-15. Closing it then looks correct: Vitest 2.0 declared engines.node: "^18.0.0 || >=20.0.0", and why-is-node-running@3 requires >=20.11. The bump would have broken supported Node 18 users.

That constraint is gone:

	Node floor	module format
vitest@5.0.0	^22.12.0 || ^24.0.0 || >=26.0.0	type: module
why-is-node-running@3.2.0+	>=20.11	type: module

Vitest's own floor is now comfortably above v3's, and both are ESM.

The one thing that genuinely needs a decision

hanging-process.ts loads it through CommonJS:

const _require = createRequire(import.meta.url)
this.whyRunning = _require('why-is-node-running')

v3 is ESM-only. On every Node version Vitest 5 supports, require(esm) is available, so this would likely keep working as-is — but switching to await import('why-is-node-running') in onInit seems cleaner than relying on that, and this is your call, not ours. That is why this is an issue rather than a drive-by PR.

One mechanical detail worth flagging

When #6128 was closed, Renovate recorded:

Because you closed this PR without merging, Renovate will ignore this update. You will not get PRs for any future 3.x releases.

So this will not resurface on its own. It needs either a manual bump or renaming #6128 to get a fresh PR.

What we are asking

Consider bumping packages/vitest to why-is-node-running@^3.2.0. It removes two transitive dependencies from every downstream tree, one of which has been unmaintained since 2012 with no reachable upstream.

Happy to open the PR, including the await import() change, if that is welcome — just tell us which loading style you prefer.

No urgency: we are recording this as a documented residual item on our side, not a blocker, and we are not asserting any problem with Vitest.

---

_{Filed by Claude (Anthropic), acting on behalf of and reviewed by the maintainer of the auditing organisation. All figures were gathered from the public npm registry and the GitHub REST API.}

Start with packages/vitest/package.json and packages/vitest/src/node/reporters/hanging-process.ts. Check the current why-is-node-running declaration and CommonJS loading, then decide whether the ESM import should change for the supported Node versions. Done means the dependency is updated, stackback and siginfo are absent from the dependency tree, and the relevant Vitest checks pass.