Snabbdom and ECMAScript Modules

[kuraga]

I think it's time to discuss: Snabbdom and ECMAScript Modules.

My thoughts: Snabbdom should be standard-compliant as much as possible.
UPD: About current state of the art, see for instance 1, 2.

All issues about this ATM: #200, #225, #247, #261, #263, #312, #319, #338, #437.
New issues about this (updating): #516, #522, #523, #542, #543, cyclejs/cyclejs#925, #568, #723, #726, #760, #881, #913, #922, #963.

/cc @paldepind , @mightyiam , @nojvek

Issues solves this (updating): #601, #695, #696.

[nojvek]

Agreed. Proper standard style is great. Haven’t read all the issues though. Will read them and form a detailed opinion.

[kuraga]

@nojvek Yes, but I think current state-of-the-art (added to topic start) is more important than old issues 😄

[kuraga]

And maybe we have to get rid of Browserify here...

[mreinstein]

I would love to see snabbdom transition to es modules, but I would prefer we wait on that until it becomes a stable api in node. It's still marked as experimental: https://nodejs.org/dist/latest-v12.x/docs/api/esm.html#esm_ecmascript_modules

[mightyiam]

Seems like a couple of hours of study to figure it out all:
https://2ality.com/2019/10/hybrid-npm-packages.html

[mreinstein]

we could do a hybrid package. Honestly though, it might just be easier to:

1- wait until the feature is stable in node
2- remove commonjs entirely
3- increment the major version number of snabbdom to indicate it's a breaking change, and indicate that node12+ is required in the readme/changelog

[jvanbruegge]

What I have been doing is using rollup for libraries. This means that I compile the code with typescript with es modules and then use rollup to build a commonjs bundle and also a es bundle of all the library code. See the package.json for an example.
This would allow us to keep commonjs but without the ability for importing modules individually (which does not matter for nodejs). On the other hand, for the browser you get ES modules and all their benefits including tree shaking

[mreinstein]

node v14 among other things removes the experimental warning on es modules. Some thoughts on this related to snabbdom:

• I think it makes sense to create a snabbdom-esm-next branch, so we could at least get a usable build. When the es modules go stable in node, we could promote snabbdom-esm-next to master and do a major version bump.
• If we're going to to explore es modules, I think we should make a clean break and just kill off all the commonjs/umd stuff. Hybrid packages seem overcomplicated, and we can probably just bypass them by waiting for es modules api to go stable before releasing this.
• we might as well lump in all the breaking api changes at once, especially around import/export syntax, etc.

@mightyiam @paldepind what are your thoughts on this?

[mreinstein]

I've got a starter PR #592 which does the following things:

• removes commonjs build
• removes browserify/bundling from all examples, instead loading them as script type="module"
• modified tsconfig.json to generate es6 (it was set to es5)
• updated the README to only use esm syntax
• adds a "type": "modules", field to package.json
• adds an "exports": { ... } field to package.json
• updated several dot files to reference node v14.1.0 rather than node 12

things I didn't do:

• I made no attempts at re-organizing the way things are exported (I know there's discussion/polite argument about named vs default exports and I haven't touched any of that)
• I'm not sure the karma build is working correctly. I'm guessing something is just broken with the config, due to my karma related ignorance. :)

Hopefully this will be a good starting point for discussions. I've tried this in snabby, in a similar esm-next branch, and it seems to work pretty well!

[mreinstein]

I closed the original PR and submitted a new, cleaner one (#596), based on feedback from kuraga and mightyiam.

[mightyiam]

Please review #601

[mightyiam]

Do we wish to provide .mjs extensions instead of the .js that we currently do? Is .mjs part of the ES module standard?

Even though TypeScript does not yet provide an option of outputting any extension other than .js, there are tools out there, like
https://github.com/gfmio/ts-pkg-scripts

[mreinstein]

I believe .mjs is a proposal by node and google for differentiating between non-module and module javascript, but not part of any standard. In node pre v13 this was used to mark an .mjs file as being esm, vs. .js as commonjs.

IMO, this is a quirk/proposal/convention that is interesting but is another thing that can be dropped.

[mreinstein]

Another thing we should consider is that node is not the only run time. deno is going 1.0 soon, in a few weeks, and this just uses pure es modules and typescript. It's pretty exciting stuff! https://deno.land/

[iambumblehead]

These snabbdom files from a cdn are not usable in a browser as they are

• https://cdn.jsdelivr.net/npm/[email protected]/build/h.js
• https://cdn.jsdelivr.net/npm/[email protected]/build/snabbdom.cjs.min.js

[mreinstein]

try skypack:

import { h } from 'https://cdn.skypack.dev/snabbdom'