Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Core: Always define globalThis.QUnit
== Background == In QUnit 2.x, we always set the QUnit global in browser contexts, but outside browsers, we only set the global if CJS/AMD wasn't detected. Except in in the QUnit CLI we still set the global anyway, because that's how most QUnit tests are written, incliuding for Node.js. So really the only case where the QUnit global is missing is: * AMD context, where QUnit would be a local argument name in the define/require() callback in each file. * Custom test runners that 1) run in Node.js, and 2) require qunit directly and 3) don't also export it as a global. I'm aware a growing proportion of users import 'qunit' directly in each test file, to aid TypeScript for example. That's a great way to avoid needing to rely on globals. But, it's not a requirement, and is not always an option, especially in a browser context with a simple no-build-step project. == Why == 1. Improve portability between test runners. Make it QUnit's responsiblity to define this reliably, as indeed it almost always already does, instead of requiring specific test runners to patch this up on their end. Esp in light of Karma deprecation, and emergence of more general purpose TAP runners, I'd like to remove this as factor that might make/break QUnit support in those. 2. Prepare for native ESM build. We don't natively support ESM exports yet, but once we do this will become a problem. To prevent split-brain problems around test registry and other state, standardise internally on whichever globalThis.QUnit was defined first, and then reliably export that to any importers, regardless of import method. Ref #1551.
- Loading branch information