[npm]: window global cannot be set

[marvinhagemeister]

A couple of testing frameworks rely on JSDOM, happy-dom and similar libraries to provide a fake DOM and browser event implementation. This usually relies on the window global being created (or patched).

In Deno the global variable window seems to be special cased. I'm not able to modify window and read the changes inside an npm package. This is a very common scenarios with the mentioned libraries. Typically they set up window as a global, and another import to the framework reads that global.

// Pseudo example
import "./set-up-happy-dom"; // <-- imaginary file, sets up global `document` and `window`
import React from "react";
import ReactDOM from "react-dom/client"; // <-- reads properties of `window`

In ESM mode the window global exists which seems to be Deno's Window object. With a CommonJS package the window global is not present which leads to a TypeError.

Steps to reproduce

1. Clone https://github.com/marvinhagemeister/deno-npm-window
2. Run deno run -A foo.js

If successful, the string "it works" should have been printed to the console.

[marvinhagemeister]

Looking a bit into this:

• Deno has its own Window object. It hat a few familiar APIs from a browser's Window object
• The window global is removed as part of the require module code here:

  deno/ext/node/polyfills/01_require.js

  Line 916 in d0c5ff4

  "(function (exports, require, module, __filename, __dirname, globalThis) { const { Buffer, clearImmediate, clearInterval, clearTimeout, console, global, process, setImmediate, setInterval, setTimeout, performance} = globalThis; var window = undefined; (function () {",

Not sure how to best solve this. Removing the window global is kinda correct for the common case as that's not available in node. But that poses the question how you can polyfill it for testing. For the test files itself it's possible to load some sort of setup module at the start, but that doesn't work for transient npm dependencies. Libraries like react-dom happily read window.event which then leads to a TypeError.

[dsherret]

We need to remove the window global from Deno IMO (#13367) then not special case it for the node code.

[marvinhagemeister]

+1 on removing it. I understand the original reasoning behind it, but having something called window is confusing imo. There is lots of existing code out there that relies on typeof window === "undefined" to check if the code is running on the server or in a browser. We break that assumption currently.

See https://github.com/search?q=%22typeof+window+%3D%3D%3D+%5C%22undefined%5C%22%22&type=code

[valpackett]

The deletion for the npm commonjs context doesn't even seem to be working 🤔

Running deno run npm:[email protected] with deno 1.45.3, the following detection code:

https://github.com/TiddlyWiki/TiddlyWiki5/blob/9069992163f114a4eec2162c059e5848f2a7b6d9/boot/bootprefix.js#L23-L28

detects both window and process globals. I can even add console.log calls to the cached npm file and see:

Window {}
EventEmitter [process] {
…
  versions: {
    node: "20.11.1",

[petamoriken]

@valpackett Please try DENO_FUTURE=1 deno run (#22318)

[bartlomieju]

This appears to no longer be an issue.