[Discussion] ambiguity between default export and named exports

I’m not sure about reason to have everything exported as a default export and a corresponding named export (I could not find a discussion around that decision), but I hope that can be revisited. In general, the way we designed the ESM was to avoid such as ambiguity. In theory, there is no problem with exporting the same thing using multiple names (including default), but in practical terms, there are:

• any consumer trying to do detection may fail (this is the case of rollup, if you try to import or require snabbdom from a project that relies on the popular rollup bundler, it will fail because rollup applies detection to normalize the exports by testing against the default export, assuming regular CJS modules will not have them, and transpiled CJS will have them but with the namespace object.
• we have enough issues with CJS and modules (which we are trying to solve via few actives initiatives at TC29 and Node CTC), we have arrived to the conclusion that the lower common denominator is to let transpilers (babel and ts) to compiled ESM to a simple CJS module. Last time we spoke to TS folks, they were onboard with this idea, I’m not sure why snabbdom needs the complexity of the duplicated entries after adopting TS.
• Last, but not least, it is very confusing for the consumer, having a CJS that contains two values, default and named export with the same thing (require('snabbdom/h').default === require('snabbdom/h').h.

Can someone explains the reasons of the duplication? I see a few options:

• refactor to either use the default export only or the named export only (I think named exports are just fine for snabbdom).
• try to work with TS folks and rollup folks to make these ambiguous modules compiled with TS to work with rollup.

@DanielRosenwasser, @Rich-Harris can you guys chime on this?

[paldepind]

@caridy

I’m not sure about reason to have everything exported as a default export and a corresponding named export (I could not find a discussion around that decision), but I hope that can be revisited.

This happened when Snabbdom was ported to TypeScript in #193. The rationally was that it allowed people to do the import in the way that is most convenient to them. But you bring up some very good arguments as for why that wasn’t such a good idea.

I think we should switch to named exports only. I don’t particularly fancy the default export feature and I think @TylorS describes some very practical disadvantages to using it.

1. Remove all the default exports.
2. Rename src/snabbdom.ts to src/init.ts
3. Add a new main file src/snabbdom.ts that re-exports all the commonly used modules (init, h, style, etc.).

This will of course be a breaking changes but should fix the issues brought up by @caridy and improve the user ergonomics as suggested by @acstll by having a main file that is more convenient.

[acstll]

What do you think about this approach?

The main module should have only named exports and have almost everything in there, so you can do:

import { init, h, modules, thunk } from 'snabbdom'

and then, submodules should be only default:

var h = require('snabbdom/h')
var init = require('snabbdom/init')
// etc…

the latter aimed at people using CJS (and good ol’ browserify), here tree-shaking isn’t even needed since you’re already requireing only what you need.