Hey! I think this is something else!

The changes you propose could be used (although: they break every package using this).
What you specify is different paths. Some could use import {} from 'x/development' to get dev code and import {} from 'x' to get prod code, that’s what you propose.

The existing code exists to do different things. They use conditions: https://nodejs.org/api/packages.html#conditional-exports. Someone can do this to get development code, from the outside.

This is already breaking builds in dependents that use "moduleResolution": "node16" in their tsconfig.json. Example I found today in remark-parse latest version:

I believe that to be a different error.

The problem is that remark-parse was last published (2 years ago) before "moduleResolution": "node16" was a thing (it’s not even in remark yet: https://github.com/remarkjs/remark/blob/main/tsconfig.json).
2 years ago, the TS CLI generated code that doesn’t work in todays TS with moduleResolution: node16.

I believe that the solution is to use a current correct TS config (e.g., like this: https://github.com/syntax-tree/mdast-util-from-markdown/blob/cd10e598ae2492c8b61131d2ace46e0ea7cc37e5/tsconfig.json), then regenerate all types in remark, and cut a new release

The existing code exists to do different things. They use conditions: https://nodejs.org/api/packages.html#conditional-exports. Someone can do this to get development code, from the outside.

I see. I didn't know about that. Thanks for the information!

Will close this PR and look into remark-parse. Thanks!