Open wighawag opened 1 week ago
I was actually banging my head against the wall on a different lib today wrt esmodules.
The crux is that esm can handle commonjs, but commonjs can't handle esm. Is there a specific tool you're having problems with?
I agree that esm is superior in every other way, but it's a jimmie rustler that support is still quite rubbish. We could possibly just compile everything to .mjs
which should work on any reasonable node version?
Yes, you could compile to both and set the correct export
The issue I have is with cloudflare worker vitest integration. I have this error : https://github.com/cloudflare/workers-sdk/issues/5367 but with tlock-js / drand-client
Error: Module cannot be synchronously required while it is being instantiated or evaluated. This error typically means that a CommonJS or NodeJS-Compat type module has a circular dependency on itself, and that a synchronous require() is being called while the module is being loaded.
❯ home/wighawag/dev/github.com/wighawag/fuzd/node_modules/.pnpm/drand-client@1.2.5/node_modules/drand-client/http-caching-chain.js?mf_vitest_no_cjs_esm_shim:4:17
❯ home/wighawag/dev/github.com/wighawag/fuzd/node_modules/.pnpm/drand-client@1.2.5/node_modules/drand-client/index.js?mf_vitest_no_cjs_esm_shim:7:46
❯ home/wighawag/dev/github.com/wighawag/fuzd/node_modules/.pnpm/tlock-js@0.9.0/node_modules/tlock-js/index.js?mf_vitest_no_cjs_esm_shim:4:24
@CluEleSsUK I made a reproduction repo : https://github.com/bug-reproduction/tlock-js-cf-worker-vitest
to see the bug
pnpm i
pnpm test
but it works when running the worker itself:
pnpm dev
# navigate to http://localhost:8787/roundAt/1729873909000
The same repo work with these modif:
drand-client: generate both cjs and esm: https://github.com/drand/drand-client/pull/87
tlock-js: generate both cjs and esm: https://github.com/drand/tlock-js/pull/46
So the 2 PR works quite well. The only thing I noticed in that when using the es module in node, it output a performance warning because of not having {"type":" module"}
Ideally the project would have "type": "module" in package.json and tsconfig set to have "moduleResolution": "NodeNext" but that cause issue with your code (you also need to use .js extension for relative import)
The best in the future might be generate 2 packages: one esm and one cjs from the same code
But for now these 2 PR are probably better than what is there.
Getting issues with modern tooling that expect es modules Not sure yet what is the exact issue but feel like there is no reason why drand-client could not publish es-module, which brings further davantage like proper dead code elimination, etc...