test: Run in node

[eps1lon]

I have to ask again: Is the purpose of this to be importable/evaluateable in node or useable without a global DOM?

This will require some work and before deep diving I want to be sure I'm not just implementing someones "I like".

If we don't care about this requirement here why do we care for it in jest-dom? It lowers interop with other dom related libraries since everybody is assuming that at least window or document are globally defined.

I traced the requirement back to testing-library/jest-dom#58 which is quite a different thing to ask. Yes instanceof checks need special treatment for cross-realm elements but those are fixable (though difficult to test properly).

But asking for no global DOM available was not part of the question, It was explicitly not asked by providing the quote from jsdom

Note that we strongly advise against trying to "execute scripts" by mashing together the jsdom and Node global environments (e.g. by doing global.window = dom.window), and then executing scripts or test code inside the Node global environment. Instead, you should treat jsdom like you would a browser, and run all scripts and tests that need access to a DOM inside the jsdom environment, using window.eval or runScripts: "dangerously". This might require, for example, creating a browserify bundle to execute as a <script> element—just like you would in a browser.

This doesn't mean you shouldn't expose a global window. Just that you don't mix these environments but rather execute your scripts inside jsdom which would result in a global window.

You can't just cherry-pick this quote and not expose a global window but still run in the node environment.

/cc @kentcdodds

[kentcdodds]

Thanks! The last time we tried to get these tests to run in node it was way more complicated, but this is pretty simple so I'm happy with that. Thank you for your work on this.

[kentcdodds]

Should we move the existing file(s) to regular test files (or just remove them?)

[eps1lon]

I'll think about that when we're getting closer to green tests 😄

[kentcdodds]

We should remove the eslintConfig property from the package.json and copy some of the overridden rules to this file.

Also the extends can be: require.resolve('kcd-scripts/eslint')

[eps1lon]

Ah it was in the package.json. I was wondering where that was coming from.

Also the extends can be: require.resolve('kcd-scripts/eslint')

👍

[kentcdodds]

Is the purpose of this to be importable/evaluateable in node or useable without a global DOM?

Yes (provided it doesn't put any unnecessary strain on maintenance of the library). It's not too difficult to support, and there are users who rely on this, so we support it. But if it becomes too much of a chore, then we can drop support I think.

I'd like to hear what other people think. A few months ago there was one contributor who was very vocal about the need for this support. I'd like to know what everyone thinks about supporting this.

[eps1lon]

I don't have a good answer how to test some tests in multiple environments. I think it makes more sense to add smoke tests for specific methods (like in #378) and run proper tests with a global DOM.