Open daKmoR opened 5 years ago
Just drop the brackets. I have no build system now so why should I introduce such complexity for no benefit? No tree shaking would be possible still, and as a testing library, size is not an issue.
import chaiDom from 'chai-dom'
window.chai.use(chaiDom)
import chaiDom from 'chai-dom'
window.chai.use(chaiDom)
that only works when using a build tool for the tests right?
if you use this directly in the browser it will fail as chai-dom is an umd module and not a native es module... and browsers can't es import umd modules.
I can totally understand if you do not want to do this - feel free to close the issue.
@nathanboktae I've exactly the same use case as @daKmoR described here: no build tools, I only use ESM in the browser. So, in order to experiment this, I created a small gist and it works just fine.
From my point of view, It would be possible for chai-dom to move to ESM the same way, and then to easily generate AMD and CommonJS using, for example, Babel (ESM to AMD & ESM to CommonJS)
FYI, I tried some workarounds before that (like using @polymer/esm-amd-loader) but failed to make them works.
On second thought, yes it'd be nice to join the ES module train. I'll have to break down and have some build tools. Previously with UMD I didn't need to :)
hey,
I would like to import this plugin as an es module so I can do something like this:
as an example for a diffrent plugin see https://github.com/open-wc/open-wc/blob/master/packages/testing/register-plugins.js
possible solutions:
index.js
? orsrc/index.js
?chai-dom.js
(will be full compatible)npm run build
before publishing@open-wc/chai-dom
only exposing es module (e.g. to reduce complexity)chai-dom
(only es module to reduce complexity)chai-dom
using rollup (if really needed)If https://github.com/nathanboktae/chai-dom/issues/7 still holds true just let me know and will move forward with 2) - although for obvious maintainability reasons I would prefer 1) or 3) but just let me know