Andrea Giammarchi

so, the current state is that given this *exports* definition in the module package that is being either imported or required: ```js { "name": "whatever", "type": "module", "exports": { ".":...

> that currently, even without this flag, fails of course it does ... that was the whole point, I want it to **not fail** and force `require("whatever")` to point at...

btw ... > that currently, even without this flag, fails if your point is that it should have a `createRequire` upfront it's fine ... I wanted to meta describe the...

P.S. I wouldn't mind a situation like this neither, as ordered JSON is also something not many care about in the wild (AFAIK) ```js { "name": "whatever", "type": "module", "exports":...

> No, my point is that today, in sync-only-code, there is no guarantee that a dual package that uses import or require conditions will be loaded only in one of...

> `require` is already a valid condition, so it's not just about dead LTSs. It's about Node.js 20, Node.js 22. apologies then that one I didn't know ... so `require-esm`...

To whom it might concern, I've created a test-case repository that should not fail in either ESM or CJS with the flag enabled: https://github.com/WebReflection/examples/tree/main/require-esm Once that works by just changing...

@joyeecheung > Am I understanding correctly that the conclusion here is that we can just add a `require-esm` condition to allow package authors to indicate a preferred ESM export, for...

> This problem seems to already exist if C were either type of module and did `import('a')`. If you read carefully that's the thing that doesn't happen at all in...

> I think TLA condition might be better and more universal as a means to detect if you are in this scenario I have no idea what TLA condition is...