Jest should resolve its dependencies from its own location rather than rootDir

[gaearon]

Create React App users bumped into this issue recently. A third party package started depending on jest-validate, and that caused npm to hoist jest-environment-node to the top of the app tree. Unfortunately, Jest resolves environment package from the project root instead of from its own Node module location so as a result, it loads the wrong (hoisted) jest-environment-node.

I think the jest package should resolve any own dependencies from its own location (just like Node resolution works) rather than from the project root folder.

[gaearon]

I guess the problem is that an environment might need to be searched for in the project folder if the project explicitly specifies it. Perhaps it's worth including the project folder if environment exists in package.json?

[SimenB]

Nice detective work, this is indeed a subtle and annoying bug.

I think it makes sense to special case (jest-environment-)node and (jest-environment-)jsdom and skip the Resolver.findNodeModule stuff for them.

[johannes-scharlach]

Rather than special module resolution logic, maybe relying on explicit versions of peer packages might be the best way to go?

Declaring all dependencies and strictly sticking to semver should also work, but semver is a lot harder to follow in monorepos according to my own experience. I've also had a similar bug with jest recently - since it's a dev dependency I wouldn't mind the lack of deduplication due to exact module resolution.

[SimenB]

I think we want to avoid peerDependencies to keep the "batteries included" feeling.

[gaearon]

I think this:

I think it makes sense to special case (jest-environment-)node and (jest-environment-)jsdom and skip the Resolver.findNodeModule stuff for them.

could be confusing for people who specifically want to pin their versions (e.g. to avoid a bug).

It would make more sense to me if Jest only searched the app folder when the app's package.json declares those as explicit deps.

[SimenB]

We can do that. Should we only check for jest-environment-* in package.json? E.g. jest-environment-jsdom can be shorthanded in config as jsdom, but we don't wanna load jsdom itself if it exists in package.json. But there is no hard requirement of environments having the jest-environment- prefix, only a convention

[gaearon]

Oh man. This is why I hate configuration shortcuts 😄

[SimenB]

@cpojer @aaronabramov thoughts?

[gaearon]

I think I expect that if I have jest-environment-jsdom in my dependencies then no matter whether I specify --env=jsdom or --env=jest-environment-jsdom, it will use my local version.

If I don't specify it in my dependencies, I expect Jest to use its local version by resolving it from jest-config.

Finally, if I specify some other environment (not jsdom or node), I expect Jest to always resolve it from my app, and not even attempt to resolve it from jest-config.

In other words, the only case in which I want Jest to resolve env from its own jest-config location is if I didn't specify the full name of the corresponding env in my package.json as a dependency. Neither node nor jsdom are considered valid third party env names.