Question around ESM support for bundlers + node

[itsdouges]

Hey folks! Love the library, definitely helps making package interop in monorepos easier. With ES what's the current support like, and how should it work for local dev?

Looking at commonjs - it uses the babel hook to transpile on the fly so local development works without any extra work, fantastic! It doesn't look like the ESM output has the same treatment though. Should it? E.g. if I have my package with "type": "module", and have it flow through into the esm module, it won't work during local dev since it's TypeScript and most bundlers (and ts-node) won't transpile node modules without extra effort.

If anyone has insight I'd appreciate it, cheers

[jrolfs]

I'm definitely curious to hear @emmatown's perspective on this, but I went somewhat deep into it by way of evaluating unbuild as a potential replacement for Preconstruct because it does provide ESM stubs (via jiti). Unfortunately, those stubs only work for Node.js, and therefore do not address linking packages to be consumed by something that uses a bundler, like Next.js. I'm honestly not even sure if hooking into the experimental and very unstable loaders API would work for that case.

You can see a bit more of my related ramblings in a comment over there.

[emmatown]

To start, "type": "module"/.mjs/etc. isn't currently supported by Preconstruct. I have thoughts on how it should be supported, specifically it will create an ESM-only package but that's not something I'm aiming to do very soon since the only thing it really allows you to do is use Node ESM-only packages.

Also, Preconstruct is unlikely to ever emit ESM targeting Node + CommonJS like some other tools do because ESM targeting Node (the import condition with "type": "module"/.mjs) + CommonJS doesn't provide value over ESM targeting bundlers (the module condition with ESM syntax in a .js file without "type": "module") + CommonJS for Node and it adds the problem of the dual package hazard.

For bundlers, you have to configure them to compile all TS and etc. outside of node_modules (even if it's potentially symlinked into node_modules) that's e.g. what @preconstruct/next does for Next. (this has been true forever with the dev command)

I went somewhat deep into it by way of evaluating unbuild as a potential replacement for Preconstruct because it does provide ESM stubs (via jiti)

Is there a particular reason why you want ESM stubs? What problems does importing CommonJS cause? (other than not having named exports (which that solution also doesn't provide), I have thoughts on solving that, though it will likely require re-running dev when adding new named exports before they're available under the import condition) especially given that solution doesn't support top-level await which is the only benefit an ESM stub like that could provide.