ci(rust): bump napi from 3.11.0 to 3.12.0

[dependabot]

Bumps napi from 3.11.0 to 3.12.0.

Release notes

Sourced from napi's releases.

napi-v3.12.0

Added

• (cli) support non-threaded WASI targets (#3353)

Commits

• 58bd87f chore: release (#3414)
• 9da8723 chore(release): publish
• 8d22196 chore(deps): update dependency oxc-parser to ^0.142.0 (#3422)
• abc30fb build(deps): bump postcss from 8.5.17 to 8.5.23 (#3421)
• 5542139 build(deps): bump fast-xml-parser from 5.9.3 to 5.10.1 (#3418)
• dc4ee8c build(deps): bump fast-uri from 3.1.3 to 3.1.4 (#3419)
• 050d985 feat(async-runtime): drain-linger surface + lock-free scheduler internals (#3...
• e0b8708 chore(deps): update dependency oxc-parser to ^0.141.0 (#3417)
• fc84940 chore(deps): update actions/setup-node action to v7 (#3413)
• ee598db build(deps): bump protobufjs from 7.6.4 to 7.6.5 (#3410)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[opieter-aws]

@strandly-the-agent review

[strandly-the-agent]

TL;DR: safe to merge — and no, this isn't #80 happening again. I built and tested every merge order of #81/#82/#83; all pass. One ⚪ nit, in a file this diff doesn't touch.

✅ Verified at 85e31a1: cargo test --features node --locked → 96 passed + 16/16 doctests (incl. the two src/js.rs:613,637 tests no CI job runs) · npm run build:debug + npm test → 41/41 · cargo fmt --check + clippy --features node clean · both .crate SHA-256s match the lockfile checksums · 0 RustSec/GHSA advisories.

On the Dependabot split. Upstream shipped napi 3.12.0, napi-build 2.4.0, napi-derive 3.6.1 and napi-derive-backend 6.1.0 in one release commit (58bd87f), and Dependabot split them across three PRs again. This time it's benign, and here's the decisive reason: napi 3.12.0's only source change vs 3.11.0 is a target_family = "wasm"-gated fix in Env::remove_env_cleanup_hook — the non-wasm arm is textually unchanged and src/tokio_runtime.rs is byte-identical, so the upstream "drain-linger / lock-free scheduler" work is not in this release. napi-derive 3.6.1 has zero source changes. No #80-style manual sync PR needed.

• #82 is a strict subset of this PR → it becomes a no-op once this merges.
• #83 is safe in either order — I verified both directions, not just the happy one.

Merge-order matrix — all five states built + fully tested

Each state: cargo test --features node --locked + npm run build:debug + npm run typecheck + npm test. cargo 1.97.1, Node 24.14.0, aarch64-linux.

State	napi	napi-build	derive	backend	cargo	JS
main (control)	3.11.0	2.3.2	3.6.0	6.0.0	✅	41/41
this PR	3.12.0	2.4.0	3.6.0	6.0.0	✅	41/41
#83 before #81	3.11.0	2.3.2	3.6.1	6.1.0	✅	41/41
#81 + #83 end state	3.12.0	2.4.0	3.6.1	6.1.0	✅	41/41
#82 alone	3.11.0	2.4.0	3.6.0	6.0.0	✅	41/41

The generated native.js / native.d.ts are byte-identical across all five. nm -D on the built addons: identical symbol lists (1 defined, 233 undefined). 8 runtime probes (process exit mid-run(), unawaited job, 32 concurrent run(), addon in 8 worker_threads, Uint8Array at/over maxFileSize + 2MiB roundtrips, 200 construct/drop cycles, 2 panic paths) behaved identically before/after — only timing noise.

Also checked: the lock diff is exactly what cargo update -p napi --precise 3.12.0 produces from main, nothing else moved, no dependency edges or feature sets changed (napi stays default, napi9, tokio_rt). napi-build's setup() — the only thing build.rs:19 calls — is byte-identical between 2.3.2 and 2.4.0; only src/wasi.rs changed, which needs target_os = "wasi" and the node feature, a combination this repo never builds (cargo tree --target wasm32-wasip2 --features wasm | grep napi → empty). And the partial-downgrade footgun can't even be expressed: cargo update -p napi-build --precise 2.3.2 on this branch fails loudly, since napi 3.12.0 requires ^2.4.0.

Not verifiable in my sandbox: release.yml's 5-triple cross-compile publish matrix (not PR-triggered) and a real wasm32-wasip2 build (no wasi-sdk).

⚪ Nit — Cargo.toml:72-74 is now stale (not in this diff, so a follow-up)

The comment above napi-build = { version = "2", optional = true } says:

# (latest is 2.3.2, which is what pairs with napi 3.x).

napi-build 2.4.0 now exists, and napi 3.12.0 requires ^2.4.0 (3.11.0 required ^2.3.2) — so it never really paired with "napi 3.x" as a whole. The load-bearing part of the comment ("stays on 2.x", "has no 3.x release") is still true, so nothing here misleads anyone into a bad edit — hence ⚪, and no reason to hold up a mechanical lockfile PR.

Worth dropping the pinned number rather than swapping it, or it goes stale again next release:

# napi-build stays on 2.x — the build-script helper is versioned
# independently of the napi/napi-derive runtime crates and has no 3.x release.
# The exact 2.x version required tracks napi's own build-dependency pin (see
# Cargo.lock) — don't bump this to 3.x or resync it to napi's major.

Questions (both non-blocking):

• .github/dependabot.yml's production-minor group (patterns: ['*'], minor + patch) should have put all three of these in one PR — napi minor, napi-build minor, napi-derive patch. It didn't, same as #76/#77. Worth digging into? Fixing that config would retire this whole class of manual reconciliation instead of re-litigating it each release.
• Unrelated to this PR, my probes surfaced a pre-existing correctness bug I reproduced on main too: a panicking builtin reports success. await shell.run('sleep nan') prints a Rust panic to stderr yet resolves {status: 0, stdout: "", stderr: ""} — src/exec.rs:2938-2942 does if let Ok(exit) = handle.await, dropping the JoinError and leaving last_exit = 0. Want me to file it as an issue?

Review method

Staged pipeline of independent fresh-context passes: triage/routing → context build → correctness/supply-chain + adversarial/repro + docs-accuracy → aggregation. I overrode triage's "skip adversarial" call because the #80 precedent made the coupling question the crux — that pass is where the merge-order matrix came from. The aggregation stage ran in my own (orchestrator) context rather than as an independent subagent: subagent spawning started failing environment-wide part-way through, and I retried twice before falling back. Flagging it since it's the stage that culls my own findings.

Findings I checked and deliberately did not raise: the CONTRIBUTING.md "Rust 1.85+" vs napi's rust_version = 1.88 gap (pre-existing — 3.11.0 declared 1.88 too), pre-existing clippy warnings in unrelated files, and two further pre-existing robustness gaps unrelated to this bump.

Machine-generated review — worth a human sanity-check before you act on it.