While I appreciate the convenience that will result from this excellent engineering, I'm concerned that this could result in a lot of mixed module files that now can only work with Bun.
Is there an option to require each file to use either CJS or ESM features, but not both? If not, may I suggest adding that option?
Seems like a case for ESLint and I agree with you.
Mixed require and import (the latter in both its static and dynamic variants) is already possible with Webpack and Vite.
I hate it and would complain about any code introducing this in any kind of review.
It's great for integration, full stop.
This is an inconvenience where tradeoffs really show and demand to study the behavioral/semantic differences.
Funnily enough, I still find Bun interesting.
Regarding import.meta., I already love Vite's dynamic import transpilation features.
They aim to work almost transparently and often do (I am not even talking about the glob feature here).
That being said, I'm unsure if Bun's way of bridging the module ecosystem gap using import.meta will be as useful.
If you ask me, frontend code should ban Node/CJS/require entirely or transpile it into static or dynamic ESM imports; respectively.
Any case where this is not possible unambiguously is a case for human intervention and code rewrite/conversion.
Is there an option to require each file to use either CJS or ESM features, but not both? If not, may I suggest adding that option?