ESM (mjs) & cjs build to support imports from ESM

[Brian Takita]

Following the technique presented in https://www.sensedeep.com/blog/posts/2021/how-to-create-single-source-npm-module.html, a library can have both cjs & mjs outputs. I'll submit a PR using this technique but am not attached to using Typescript, as long as there is an mjs & cjs build.

[Luke Edwards]

As described earlier, this would be a breaking change. Easy to do, but on its own is generally an unnecessary shard of its dependents ecosystem.

Sade (and mri by extension) have nothing to gain from offering native ESM via exports. This is because they're both a default export and use >95% of their code on every usage. AKA, there's nothing to be treeshaken away. These two libraries (specifically) would operate the same as a native ESM version in a bundled context.

Adding native ESM to these two would only help a browser environment, which neither of these target (or can function within).

So, all that said, not going to add a new major version just to add an exports mapping.
I've been combing thru my packages and evaluating opportunities to introduce other breaking changes so that it's actually worth the version. These two are towards the bottom of the list for reasons mentioned above... there's nearly 0 benefit to be had. I will eventually add support, but I don't want to do it just because.

As of right now, that'd make for 2+ versions of sade floating around its 416 dependents. And 2+ versions of mri floating around its 427 dependents.

[Brian Takita]

I mistakenly removed "main" & have since readded it in the PR branch. Would having "main", "module", & "exports" make this a non-breaking change?

I was getting an error importing from an ESM in node.js. We will see if others get this issue as packages transition to "type": "module".

--- edit

I saw your answer re: "exports" being a breaking change at lukeed/bundt#7 (comment)

I can maintain an ESM fork using a multi-repo for now & wait for you to make the move.

[Luke Edwards]

Adding "type": "module" is also breaking.

Adding a "module" pointed to a new file is not breaking and can be done; but honestly it's not needed. If you're already bundling, it will literally make zero difference to your setup. Even if you're not bundling, you can import from sade currently already. ESM can load CommonJS (but not the other way around). Bunch of examples/comparisons here: lukeed/rewrite-imports#14 (comment)

[Brian Takita]

I was unable to import sade from an ESM without bundling. I fixed the issue then moved on, due to scheduling pressure. If I can reproduce the issue again, I will do so.

[Ben McCann]

@btakita not sure if this is the issue you hit, but I ran into issues using sade yesterday. It seems that @rollup/plugin-commonjs can't handle sade/mri properly for whatever reason.

Luke helped me work around it with the following:

    plugins: [
      alias({
        entries: {
          // force rollup to use the commonjs version of mri until there's an esm version of sade
          mri: require.resolve('mri/lib/index.js')
        }
      })
    ]

Personally, I'd still love to see an ESM version distributed since it's currently quite difficult for users to use sade with Rollup. Rather than distributing a CJS version that needs to be converted to ESM, it'd be nicer to just distribute the ESM version. It'd add a bit to the size of the distributable, but we burnt a lot of time figuring this out yesterday and bytes are cheaper than developer time.