[striking]

That's all well and good, but what about those of us that already have a mountain of Jest tests with mocks that aren't supported in ESM mode? https://github.com/jestjs/jest/issues/9430

I've definitely worked around my fair share of CommonJS issues but until ESM "just works" I'm slightly pained by how aggressive the tone of this article is.

[photonerd]

That’s mostly because of how Jest absolutely brutalizes the Require stack. It’s a problem with Jest AND CommonJS, not ES Modules.

In fact it’s a very illustrative example of why CommonJS should be taken out back and shot.

[bastawhiz]

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.

[striking]

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.

[rektide]

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

[briantakita]

> 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?

[freedomben]

This is exactly my beef. The testability with commonjs is great, being able to easily mock dependencies is a huge boon for testing. I'd have no issue using only ESM if it had feature parity, or at least some way to achieve dynamic loading.

[briantakita]

Unfortunately, migrations are necessary when major releases occur. At some point, the argument to cling onto old tech which holds back the entire ecosystem needs to be deprioritized. Years have passed already so it should not be a surprise when the ecosystem moves on.

Re mocks, an ecosystem should not be held back solely due to an arcane edge case. The apps that use test doubles can be rearchitected to support test doubles to the programmers' satisfaction. Most people do not use test doubles & the benefits of ESM & not having to deal with CJS outweigh the downsides of losing some convenience in mocking modules.

This is something that will not be popular with clingers to CJS, but it is something that will benefit the wider ecosystem. The vocal minority which is holding back the ecosystem should start making plans to migrate because it is in the process of happening right now...

So I think the general resentment is having to do extra work to support CJS which is not standard across all JS platforms...and some legacy libraries are still written in CJS requiring an interop. So it would be great to not have to do this extra work to support the legacy CJS on Node.js when every other JS platform is using ESM. In this case, one person's convenience comes at a cost to everyone else & at some point, that one person is going to have to suck it up & do the work to support his use case...just as everyone else had to do the work to support the legacy CJS for years now.

[qbasic_forever]

I did not perceive an aggressive tone from the article, I think you are projecting your annoyance with the Jest project and your architecture choices.

[striking]

I can't tell you your perception is wrong, but I generally don't unload ornate rhetoric like "insidious saboteur" or verbs that relate to strong imagery like "rip out", "bury" when writing about code unless I intend for my tone to be aggressive.

My code works fine and the article isn't doing itself any favors by mocking me (heh) for thinking so.

[olias]

Use vitest.

[striking]

We're trying, we've had compatibility issues with node-canvas and our older version of graphql-js

[TheCoelacanth]

Jest mocking is one of the worst anti-features ever invented.

We would be much better off if it had never been created.