chai
chai copied to clipboard
index.mjs imports invalid module
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.
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...
@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.
@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:
https://github.com/chaijs/chai/blob/3a8c49a70733ac7f4570925415e9a8544e2ee1c3/lib/chai.js#L25
it then imports addProperty
here:
https://github.com/chaijs/chai/blob/3a8c49a70733ac7f4570925415e9a8544e2ee1c3/lib/chai/utils/index.js#L94
which then imports chai here:
https://github.com/chaijs/chai/blob/3a8c49a70733ac7f4570925415e9a8544e2ee1c3/lib/chai/utils/addProperty.js#L7
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.
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.
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 😂
@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.