Importing in a `type=module` project fails

First: thanks for the simplified version of state management. So glad I found it, so sad it took me so long 😉.

I created a small project, where the package.json sets it to be a ESM project, by type=module. See https://codeberg.org/wolframkriesing/bug-exploration-zustand-and-esm/src/branch/main/package.json#L4

I ran into two issues, that are somehow related to #201 but I am not sure exactly what’s the root cause.

The Problem(s)

I wanted to get zustand to be testable with mocha in an ESM setup. But I ran into:

1. When using type=module and importing zustand/vanilla mocha says there is no such file. No idea what that might be. This is the JS file and the error it throws: https://codeberg.org/wolframkriesing/bug-exploration-zustand-and-esm/src/branch/main/src/vanilla.test.js
2. When importing zustand/vanilla.js the default export is somehow broken. A change of exports.default = create;
   to
   module.exports = create;
   in zustand/vanilla.js would fix it. This sounds like a packager problem in zustand? https://codeberg.org/wolframkriesing/bug-exploration-zustand-and-esm/src/branch/main/src/vanilla-js.test.js

Is the ESM setup just not there yet, and not recommended? I had hoped to go there gradually. How do others solve this issue?

[wolframkriesing]

Sounds like a tricky one, not fun. What about a (challenging) suggestion: Why not ship ESM only? One file, only import/export, pure ESM. Why?

1. this is where JS is going
2. let the user transpiler if they need it (anyways)
3. much simpler to maintain

Sounds more like a major version thing, and it might prevent more compat work?

[rschristian]

I don’t know of a pattern that would allow you to get rid of the preceding require. Node’s the limiting factor there in the keys it has implemented.

As for the dual hazard, I suppose the only way to tell is to test. I’ll try a few things out, see if I can get something to break.