Added module entry point (+ refactored build setup)

[Andarist]

What this gives us?

1. tree-shakeability
2. webpack being able to scope hoist this library (ModuleConcatenationplugin)
3. ensuring that you always produce a "flat bundle" which results in better uglifying and such
4. smaller size (before - 1.42KB, after - 1.16KB, reduction 19%)

[jxnblk]

Thanks for the PR!

Generally I like to keep bundlers/etc. out of libraries. This whole setup feels very heavy-handed; is there not a simpler way to handle es bundles and support tree shaking these days?

[Andarist]

Generally I like to keep bundlers/etc. out of libraries.

I don't really see how it differs from having a babel setup in place (which you did). Advantage of this approach is that it is a single file/script that outputs both module types at once - esm and cjs. And it produces "flat bundles" by default - which is not relevant at the moment as this library is in a single file, but might be relevant in the future if you decide to add more files.

One alternatives is to have 2 build scripts, something along lines:

"build": "npm run build:es && npm run build:cjs",
"build:es": "cross-env BABEL_ENV=es babel src --out-dir es",
"build:cjs": "cross-env BABEL_ENV=cjs babel src --out-dir cjs",

And apply modules transform conditionally in the babelrc (like in this PR). Ain't really sure if this makes things easier.

One great alternative is rising on the horizon - microbundle, which should ease part of this whole setup and hide most things behind its implementation (which is just opinionated wrapper around rollup) and a single CLI command. But at the time being it has no babel support yet (it uses buble), and I don't feel yet like using it, because of this.

Bottom line - if you want to support tree-shaking for esm users and also have cjs entries, so there is no problem when requiring things in tests etc, then you have to transpile somehow conditionally with 2 targets in mind.

[jxnblk]

I doubt this library will ever be more than one file. With babel, it simply transpiles a new version of ES syntax to one that's more widely compatible – i.e. it's still just JavaScript, whereas a bundle changes how module syntax works. If this library is published to npm, I'm relying on the CommonJS module, which is how npm works.

I'd rather hold out for a solution from npm and the node community for using the ES import syntax than relying on a bundler and a custom setup that is likely to change, if that makes sense

[Andarist]

i.e. it's still just JavaScript, whereas a bundle changes how module syntax works.

Not sure what do you mean by that, output files are "just JavaScript" - no matter if you use babel alone or a bundler (rollup in this case) for transpilation. Both produce the same CJS output when it comes to module syntax (if you use more than default export, which you do).

If this library is published to npm, I'm relying on the CommonJS module, which is how npm works.

This is not really true, unless you stick to using node or older tooling. If you use webpack@2+ (or other module aware bundler) you are probably already relaying on non-cjs files - if you rely on libraries that have "module" field and there are already a lot of them in the ecosystem (styled-components included).

I'd rather hold out for a solution from npm and the node community for using the ES import syntax than relying on a bundler and a custom setup that is likely to change, if that makes sense

Well, this PR attempts to cover both cases - this is very much usable in node (for SSR etc), node will grab cjs file specified by the "main" field in package.json. Bundlers will be able to pick up the file specified in the "module" field and benefit from it - tree-shake, scope hoist.

It doesnt require a custom setup from user's perspective, and when it comes to library developer - you are already having a custom setup with babel, conceptually it isn't any different from what is presented here.