ESM build

[matthewp]

Note

QUnit 3.0 introduces an ESM distribution (qunit/esm/qunit.module.js), alongside the existing qunit/qunit.js file in the CJS format. Both are available for download.

Browser support for the CJS format is the same as in QUnit 2.x (including IE 9-11 and Safari 7+). If you choose to opt-in to the ESM format, note that this does not support running tests in IE 9-11 or Safari 7-9.

When testing in Node.js, we automatically select a format based on require() vs import. Both share the same instance internally so mixed usage is okay. If some configuration files, plugins, adapters, test runners, or test files import QUnit differently, everything still works fine.

---

An ESM build would be nice given that browser support for modules is mature these days.

Currently to use modules when testing with QUnit I do something like this:

<script src="https://code.jquery.com/qunit/qunit-VERSION.js"></script>
<script type="module" src="./test.js"></script>

local_qunit.js

export default window.QUnit;

test.js

import QUnit from './local_qunit.js';

Given that qunit is using rollup for the build it should be relatively straight-foward to add a second build output for use with <script type="module"> so you would be able to do:

import QUnit from 'https://code.jquery.com/qunit/qunit-VERSION.mjs';

...

[Krinkle]

@matthewp There shouldn't be any need to bring the QUnit object in as a module import. It is meant to bootstrap the HTML page for you and takes care of itself. The test suites should reference QUnit API as a host variable, similar to how you might interact with window, location, URL etc.

Could you explain what problem or advantage you are currently addressing by using QUnit in this way? I'd prefer not to maintain multiple build outputs, but I could consider it or come up with simpler solutions, if I understood the use case better. Thanks!

[matthewp]

Maybe I'm not following but I need to reference the QUnit object to do:

QUnit.test('my test')....

The advantage to it being available as a module is the same as for any module.

[Krinkle]

@matthewp The QUnit object is always available. Does it not work from your ESM-loaded test.js file? There is no need to import qunit a second time from inside every test suite file.

[reno1979]

Same problem here.

Test modules that require QUnit al import QUnit, and I need to build them before the can be used.

[matthewp]

@Krinkle Yeah maybe I wasn't being clear about my reasoning here. Yes, QUnit works fine as a global via a classic script tag. There's nothing that doesn't work about it. It's just that I would rather my modules explicitly import their dependencies and not rely on external dependency management (having to remember to always include a script tag in the right order on the page). So the reason to have QUnit be a module is the same reason to have any dependency to be a module.

[jdittrich]

It's just that I would rather my modules explicitly import their dependencies and not rely on external
dependency management (having to remember to always include a script tag in the right order on the page).

Same for me: Having explicit imports makes code easier to reason about for me: When I read the tests, I want to know where objects come from. Currently I need to know that QUnit comes as a global when I run my tests in a browser window.

[Krinkle]

This will also resolve #1724 once done.

[Krinkle]

Quoting here to ease discovery.

From #1729 (comment):

[…]

I'd like to make it safe in QUnit 3.0 to load qunit.js multiple times. Today we consider this an error and throw an error. To adopt ESM we will likely have to provide a separate build. For projects that reference QUnit globally, with one part of the test stack responsible for actually loading it, this will work fine. They can switch or not switch depending on their needs and requirements, it's fine either way.

For projects that reference QUnit by importing it in individual plugins, integration layers, and/or test files, there's a good chance that there will be mixed use in practice. If we don't do anything to prevent it, this will cause various split-brain problems where config/plugins are missing, or tests are divided, event handlers firing multiple times, etc. This also came up in discussions for jQuery at jquery/jquery#5429 where similar concerns were raised. For QUnit, we're a bit more flexible in some ways and less flexible in others.

I'm thinking of making QUnit safe to load multiple times. We're not concerned about clashing versions of QUnit. These are going to be the same version. Whichever loads first will own the state, and subsequent imports (e.g. CJS first then ESM, or vice versa) will effectively resume that instead of exporting a different local copy.

[…]