Let CLI load ESM files that have a .js suffix

[frank-dspeed]

Tell us about your runtime:

• QUnit version:
• What environment are you running QUnit in? (e.g., browser, Node):
• How are you running QUnit? (e.g., script, testem, Grunt):

What are you trying to do?

i am trying to run a test that is writen in as .mjs file so all this cli stuff does not work as it depends on require.
Code that reproduces the problem:

If you have any relevant configuration information, please include that here:

What did you expect to happen?

implament a esm version

What actually happened?

[trentmwillis]

@frank-dspeed you should be able to use qunit --require esm with the esm package.

[frank-dspeed]

@trentmwillis good idea i did it with a little other trick i keep the unit test files as .js and do dynamic import as that allows esm but it would be great if there would be a nativ qunit cli that accepts .mjs input

at present i needed to transform all tests to async because of the dynamic import. ESM Works but it uses a trick and transpils i don't want to go that route i am advocat of standards and transpiling is something that i want to drop all over in all JS Packages. the Time of Transpil Compile build is over. We have terminated all cross environment issues over the last past years now only package maintainers need to follow up.

[trentmwillis]

That's reasonable; I'd like to see official support in the QUnit CLI for ECMAScript Modules, but the API is currently still "experimental" in Node. Given the limited bandwidth of the maintainers, we'll likely wait until the API reaches "stable" before implementing it.

Until then, our recommendation would be to use esm or some similar tool.

[frank-dspeed]

@trentmwillis your wrong the new node 12 and 13 have experimental-modules unflagged its time to do it.

Interoperability is finished.

import() works in both cjs and esm to require both

in ESM you can do createRequire to use require and you can as pointed out import()

[frank-dspeed]

lets create a qunit-es binary that does use import() then all tests can work out of the box no matter if cjs or esm

[trentmwillis]

Can you please point me to something official from the Node.js organization saying that the API is stable? You've not provided any proof that it actually is, so just saying "your wrong" does not make me inclined to agree with you. On the other hand, I have linked to the official Node.js documentation above stating the API is still "experimental". In fact, you even just referred to it as "experimental-modules".

Note, I'd be open to a PR to implement support for this (with proper tests) for the current API, but as noted above I don't think any of the maintainers currently have time to implement this. And just saying "its time to do it", does not mean that we have to do it. The beauty of open source software is that if you have a solution, you can submit it as a pull request.

[frank-dspeed]

@trentmwillis simply ignore it or take it i don't care out of my view its total ok if you don't want to jump on that train now. There are alternatives like jest that do that and they have nice importers for qunit tests .

i my self created a import based qunit for my own needs.

You can Open up the issue in 3 years and you will see no change in that api as there are only 2 people working on it import behavior will stay as is modules in general are experimental in nodeJS not the import api.

[sylvainpolletvillard]

The qunit --require esm solution no longer works since Node 12.16 due to this error: standard-things/esm#868

It it correct to claim that QUnit can not be used to test an ES Module ?

[frank-dspeed]

@sylvainpolletvillard that claim is not correct as there is ESM Interoperability via dynamic import

src/my-esm.mjs

export const numberFour = 4

tests/CJS.js

const { test } = QUnit;

test( "an async test", async t => {
  const { numberFour } = await import('../src/my-esm.mjs')
  t.equal( numberFour, 4 );
});

https://api.qunitjs.com/QUnit/test at the end

keep in mind that the rules for ESM interoperability do apply here

Solutions aka the Rules of current ECMAScript Development 2020

• your source should be in Valid ECMAScript with .mjs extension
• static type checking via typescript checkJs true and JSDOC annotations in your code.
• package.json
  • Only devDependencies
  • { "type": "module" } //is the future use commonjs for backward compat
• vscode don't support .mjs right because of typescript it needs .mjs support workaround is use package.json with type module and then .js at present till .mjs support lands in typescript
• don't do import without extension don't use package JSON or any lookups in your own code
• use rollup to build ECMAScript bundles that are consumed
• dev should not get packaged and stay in git
• bundles should work without package.json
• if you want to use node_modules as vendor maintained packages be aware of the fact that they are not clean coded go for es-modules
  • modules can be fetched how you like it via wget or any method and then get bundled up.
• run inside a container engine to apply isolation and do awsome repeatable infrastructure that scales.

the text is from my Article about ECMAScript 2020

https://gist.github.com/frank-dspeed/de322e0bd7e0daf2dbdb2ccaeee34665

[sylvainpolletvillard]

The dynamic import solution worked for me. Top level await is not supported, you have to wrap it in a QUnit.test. To avoid reloading the same module in every test, I assigned it to a global variable. I also had to change all my test specs extensions to ".cjs"

qunit test/index.cjs

index.cjs:

QUnit.test("loading module", async t => {
  const globals = await import("../src/mymodule.mjs")
  Object.assign(globalThis, globals)
  t.ok("MyModule" in globals, "libarary correcty loaded as module");
});

require("./test.spec.cjs")
require("./othertest.spec.cjs")
require("./yetanothertest.spec.cjs")

So it works, but the setup is a bit awkward and poorly documented. I hope we will get support for static imports soon with QUnit CLI.

[frank-dspeed]

@sylvainpolletvillard then you don't readed my Rules correctly :) i need to rewrite them maybe the most easy solution is to store a package.json inside the tests/ folder and content is { type: "commonjs"}
then you can name them .js and inside your main package json you do type: module

node-resolve will always get package.json relativ to the import :)

[frank-dspeed]

also note that you can go for the npm esm package and use that as loader.