deno

This crashes when built with but interestingly works with and also . Error message: I compiled this on Linux and also cross-compiled to Windows and macOS and tested on these systems; interestingly the macOS one runs fine but the Windows one crashes with the same problem. My use case is that I'd like to use an SQLite library with encryption but they all use the Node-API (Turso does, too); I'm assuming this affects some other packages, too. Claude has a suggestion what it thinks the reason is which I have pasted here: Claude's Thoughts Likely cause Node-API addons resolve by against the main executable. produces a single binary that exports them. produces a thin launcher plus a sibling holding the runtime, and the launcher exports nothing — so the lookup cannot succeed even though the symbols are present in the process. Exported symbol counts (): The runtime is not a link-time dependency of the launcher — it does not appear in : So the launcher s it at startup. A plain defaults to , which keeps the loaded object's symbols out of the global lookup scope — which is exactly why for fails despite the symbols being present in the process. Loading the runtime with **** should be sufficient. Platforms macOS passing is consistent with the cause above rather than an exception to it: when is called with neither nor , dyld's default on macOS is , so the runtime's symbols land in the global scope automatically. glibc's default is , and Windows has no global symbol namespace at all — needs the handle of the module that actually exports the symbol, and the launcher does not. In other words the only platform that works is the one whose loader already does implicitly what the fix below asks for explicitly. Version: deno 2.9.5 (stable, release, x86_64-unknown-linux-gnu) v8 15.0.245.2-rusty typescript 6.0.3 I think this is related to #35269 / #33441 .

Summary Fixes #36519. (which backs Node's ) was missing the permission check that the other inspector-state entry points gained in #36465 (, , and ). Without this fix a script that has been granted but not can read the actual bound inspector port (including the ephemeral port chosen by ) via , even though from the same script is correctly rejected with . That port together with already reveals everything 's check is meant to protect, so this op looks like it was missed in the original consistency sweep rather than deliberately exempted. Changes : add to , mirroring the call sites in and . Switch the op to take since the permission check needs a mutable borrow. : add two regression tests: : runs with and (no ) and asserts that falls back to Node's default instead of leaking the bound port. : runs with and asserts that reflects the actual ephemeral port (not ). Implementation note is declared and returns a plain , so it cannot propagate a . On denial the op silently returns , and the existing polyfill (in ) already falls through to the default when the op returns . So the property stays readable and matches Node's semantics, while the real bound port is no longer leaked. AI assistance Parts of this contribution (the patch structure, the test scaffolding, and this description) were drafted with the assistance of an AI coding tool, which I then reviewed and adjusted before submitting.

TypeScript's bundled libs now cover several APIs we were forwarding, and TypeScript 6 ignores . This drops the duplicate declarations (, , base64/hex, ), restores so includes it again (same regression as #24489), and removes the now-dead lines from Deno-owned libs. / stay in both and extras. Schema examples add and drop the empty iterable libs. AI Disclosure AI agents write the code, and I review and edit it myself.