Broken access to Node.js modules cache

[medikoo]

🐛 Bug Report

require.cache is broken in modules tested by Jest. This is a public, documented feature, while rarely, it's occasionally used by some modules (e.g. https://github.com/sindresorhus/meow/blob/258659a6e4cf102ef09a7c27efcee1e953808725/index.js#L14)

To Reproduce

Created two modules a.js as empty file, and b.js with content as:

require("./a");
module.exports = require.cache[require.resolve("./a")];
console.log("Expected cached module: ", module.exports);

When run through jest this module exports undefined

Expected behavior

require.cache should not be affected, e.g. above module when run directly via Node.js will log module instance.

Link to repl

https://repl.it/@medikoo/broken-modules-cache-access

Env info

Paste the results here:

System:
    OS: macOS High Sierra 10.13.5
    CPU: x64 Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
  Binaries:
    Node: 10.7.0 - /usr/local/bin/node
    Yarn: 1.7.0 - /usr/local/bin/yarn
    npm: 6.1.0 - /usr/local/bin/npm
  npmPackages:
    jest: ^23.4.1 => 23.4.1 

[thymikee]

Duplicate of #5741

[medikoo]

Duplicate of #5741

Ok, but #5741 was closed without fixing.

So agreement is that it's ok to break public Node.js API?

[thymikee]

It's by design and Jest provides workarounds for that:

• jest-resolve not honoring require cache #5120 (comment)
• jest-runtime makes each module to have its own modules cache #4940 (comment)

[medikoo]

and Jest provides workarounds for that

How they're supposed to work for dependencies?

It's by design

Why agreed design is to replace known public API with custom (Jest specific) one? As I understand the goal is to isolate environment for tests, and from what I see same could be achieved maintaining same API contract, isn't it?

[thymikee]

Maybe we could add support for that? I didn't think about it thoroughly though.
cc @cpojer @SimenB

[SimenB]

Populating require.cache should be easy enough, the issue is that if the user deletes from it, we won't respect that deletion - and we'll get bug reports on that instead. And we don't support clearing single modules from the cache currently either.

So - while it's easy enough to populate require.cache, any use case that I can imagine will still not be possible without much larger changes

[medikoo]

we won't respect that deletion

Well that'll be just another bug on a side of Jest, so it's obvious you'll receive bug reports :)

Other issue I observed is that popular (test engine agnostic) proxyquire library also doesn't work with Jest cause that.

I know that Jest brings it's own custom API to achieve module mocks, but as I looked it's quite limited and not as flexible as what can be achieved with public Node.js endpoints (and tools as proxyquire)

What's even more controversial is that it implies quite controversial vendor lock-in, as once we agree to rely on those custom Jest endpoints, it becomes harder to switch to other solution.

[SimenB]

Feel free to send a PR for it. With Proxy we can actually intercept a delete, so it should be possible (which it wasn't when the current API was designed).

No guarantees it'll be merged though - what we have today covers close to all use cases already, so any change is potentially disruptive

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.