It's a problem with Jest and CommonJS only in so far as it's a problem with mocking in general: native ESM imports are read-only. You can roll your own dependency injection or use tools that parse/rewrite your imports at runtime, but this is hardly a good solution. I think the parent's comment still stands: there's a big gap remaining.
Are you saying I just shouldn't have access to that part of the runtime? I've also done my fair share of `require` hacking, and it's led to things like hot reload and lazy loading for Node backends. There's a lot of value in being able to mess with that part of the stack.
I really wish this sort of hackerly mojo was available in the browser too.
Being able to hot reload & instrument modules is power we should have. Will some people greatly mess it up & create hard to maintain software? Oh yes. But let not the bottom of thr curve be an excuse to clip off the top half of the bell curve. Ad Astra.
As esm was being specced out in es2015, there was an expectation there would be follow on work for a registry, where modules could be managed by the runtime.
That never happened. Heck, 2023 and we still don't have actually modular modules in web workers: there's no import-map support or spec! Issue #2 in import maps... 2. https://github.com/WICG/import-maps/issues/2
> As esm was being specced out in es2015, there was an expectation there would be follow on work for a registry, where modules could be managed by the runtime.
I've seen routing architectures that support HMR & runtime management of modules use an Object with methods that call `import('module-name')`. Would dynamic imports be sufficient to support the use case you described?