Allow custom environments to have core (builtin) modules

[aaronabramov]

We already have a concept of builtin modules (that come from require('Module').builtinModules) that bypass all jest transforming/caching mechanism.

This PR introduces the same concept to our Environment object.

The use case i have is testing electron apps, where you have an additional list of modules (like require('electron')) that are available, but they're resolved differently (usually using asar packages). Which means you can require them in a raw process, but requiring them from within a Jest tests will break things.

I didn't use ProjectConfig for this, because i wanted to avoid having to configure too many things. And since this is probably only relevant when you already have a custom environment, it's easier to have everything in the environment definition

[codecov-io]

Codecov Report

Merging #6193 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6193      +/-   ##
==========================================
+ Coverage   64.37%   64.38%   +<.01%     
==========================================
  Files         219      219              
  Lines        8453     8454       +1     
  Branches        4        3       -1     
==========================================
+ Hits         5442     5443       +1     
  Misses       3010     3010              
  Partials        1        1

Impacted Files	Coverage Δ
packages/jest-runtime/src/index.js	72.98% <ø> (+0.08%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7f74710...17469cb. Read the comment docs.

[aaronabramov]

would custom resolver be a better solution for this?

[SimenB]

I do wonder if a custom resolver is better. It can just extend the default one, but override isCoreModule

[aaronabramov]

oh.. it seems like we only support providing a custom resolve function, but not the Resolver class. so it seems like it has to be a combination of both :(

[aaronabramov]

yeah. it seems to complicated, because there are two parts that need to be modified:

• resolving a module
• requiring a module

i monkey patched it on a Resolver object for now, i'll see how that works first before trying to get it into jest

[SimenB]

Hmm, I think we should support replacing the resolver entirely, not just parts of it. The use case of electron is really compelling

[aaronabramov]

@SimenB yeah! i think it makes sense. right now we don't even expose default_resolver.js, so custom resolver will have to reimplement the whole mechanism

[aaronabramov]

i can work on it if that's the way we want to do things :)

[SimenB]

I think that makes sense, at least. And exposing the default resolver for extension

[github-actions]

This pull request 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.