Open bedeoverend opened 7 years ago
Note: anyone currently facing this problem can get around it by importing simpla.js
directly, e.g. use this snippet in your code:
import Simpla from 'simpla/simpla.js'
window.Simpla = Simpla;
this bypasses the default module
entry point your bundler might be using.
Simpla v3 no longer points to a borked ES build as the main
, but now there's no way to import an ES6 build for module-aware bundlers. So this is now a minor enhancement rather than a minor bug.
As per mentioned in #86, I think we should have ES and UMD builds for each part of Simpla, so that will be:
For UMD builds that'll mean following a naming convention to add to the global namespace e.g. Simpla.X
or SimplaX
the former being better IMO as it restricts global pollution to just the 1 Simpla
Only problem with Simpla.X
is ensuring nothing clobbers each other, so you don't have to depend on loading order. Eg: If Simpla.[SomeExternalThing]
loads before Simpla core lib.
Currently the
module
field onpackage.json
points tosrc/simpla.js
but really it should point to a separate build, that's been transpiled, but not bundled. This means that whatever module bundling system consumers are using will still be used, but it won't need to be transpiled. As it currently stands, users can come up against this bug but more generally it'll require them to transpile our source, not just bundle it.An interim measure would be to change where
module
points to - just the transpiled, bundledsimpla.js
in root. The main reason behind giving users an ES module target is so they can tree shake, but as we only have one defaultexport
, Simpla, this is pretty redundant.