ESM build

[matthewp]

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.