simplajs / simpla

Open, modular, and serverless content management for a modern web
https://www.simplajs.org
MIT License
527 stars 36 forks source link

Create ES module build #74

Open bedeoverend opened 7 years ago

bedeoverend commented 7 years ago

Currently the module field on package.json points to src/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, bundled simpla.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 default export, Simpla, this is pretty redundant.

bedeoverend commented 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.

madeleineostoja commented 7 years ago

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.

bedeoverend commented 6 years ago

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

madeleineostoja commented 6 years ago

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.