Author ES modules, use Rollup for bundling #6
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Greetings, stranger!
This PR moves the source to ES6 modules, and uses Rollup (via https://github.com/developit/microbundle) to output CommonJS, UMD, and ES modules; it takes the options directly from the
relevant
package.json
fields, which is nice.ES6 modules are nice because they can be statically analysed by bundlers. The library is tiny, so tree shaking / dead code elimination won't do much (plus the functions link between each other). Still, ES6 modules can be hoisted to the top scope by bundlers, and are easier to integrate (especially true for Rollup).
This turned out both simple and a tiny bit annoying, here's notes:
Exports
Using both default exports and named exports is allowed by the
spec, but not recommended. If we have both, then the usage
with require() needs to access .default, which is breaking, and
also can mess with bundling/scope hoisting. I moved the exports to
named only, and the tests run the same as before.
This is the important thing here, and I am not sure if it breaks
something else. I am curious to test it with typescript synthetic
default imports (
import * as cssNs from 'css-ns'
), which until 2.7have odd behaviour. If it does break, then I defer to you :)
Tests
Tests now use the files in dist/, since they are CommonJS and node
does not yet understand ES modules.
NPM -_-
One annoying thing atm is that npm install adds many versions of
acorn, which leads to errors with microbundle. Using yarn fixes
that. There are no dependencies, so this shouldn't change anything
but it is something to consider.
Publishing helpers
In addition to the modules field, I added scripts for publishing
to npm and bumping the tag, plus the "files" option. It should
match the instructions at the end of the README, but we can omit
it / split to another PR / anything.