index.mjs imports invalid module

[arv]

The file index.mjs is trying to import index.js. index.js has no exports so you get a SyntaxError.

Any chance of publishing a valid ES module version of chai? There are of course alternatives like using @esm-bundle/chai or skypack but it would be nice if the source of truth was using ES modules.

[keithamus]

Thanks for the issue @arv.

PRs are welcome. There have been multiple attempts but it seems really difficult to satisfy all bundlers and tools. I think we might need to just refactor to use ES modules and release a breaking change which drops support for anything that doesn't use ES modules...

[RebeccaStevens]

@keithamus I don't think it's possible to support both without using a build tool.
I could submit a PR to add rollup and get it to output for each of the different environments if you like.

[43081j]

@keithamus just ran into this myself, there's also a problem preventing us from transforming chai at build time to CJS: circular imports.

chai imports its utils here:

chai/lib/chai.js

Line 25 in 3a8c49a

var util = require('./chai/utils');

it then imports addProperty here:

chai/lib/chai/utils/index.js

Line 94 in 3a8c49a

exports.addProperty = require('./addProperty');

which then imports chai here:

chai/lib/chai/utils/addProperty.js

Line 7 in 3a8c49a

var chai = require('../../chai');

this isn't valid in ESM. so even if we use a build process to convert chai into an ES module (e.g. rollup's commonjs plugin), it will fail at run time thanks to this impossible circular import.

time has also moved on a lot by now. im pretty confident we could just move chai to use ES modules in the source and have a build process produce a commonjs version. we'd have to ship both versions in the npm package (increased package size) but it means it'd be a pure ES module and still a CJS module.

[keithamus]

Thanks @43081j. I agree. Moving to es modules would be a good move. Annoyingly there's a lot of work involved, but I think that's the priority for Chai 5. I have been incredibly short on time lately though, due to a variety of other commitments, as have the rest of the chai maintainers.

[43081j]

makes sense.

from a quick look, i can see the whole use(...) concept will make it difficult - allowing patching of the exported module by third party packages basically.

won't be as straight forward when the module doesn't exist as a variable. that would probably be better off being reworked so it doesn't mutate the module itself but keeps track somewhere of extensions.

in other words, i can see why its a big job now 😂

[43081j]

@keithamus something like #1498 maybe (based in 5.x.x branch fwiw)

good if some day you and/or the other maintainers get chance to have a stab at that, or help finish off this one if its along the right lines.