Make jest-environment-jsdom a peerDependency in jest-environment-enzyme

[Methuselah96]

This increases flexibility for developers using this package. For example, I've been waiting for a couple months to upgrade to Jest 25 (see #334). If this were a peer dependency, then I could have upgraded right away and it would have just automatically used the new version of jest-environment-jsdom.

[ljharb]

It could still not have been upgraded right away - peerdeps are strict requirements, and if npm ls does not exit zero, your dep graph is invalid and you can’t rely on anything working. npm 7 will fail installs if your peer deps are invalid.

That said, it should indeed be a peer dep.

[ljharb]

It will need to be both a peer dep and a dev dep, or else tests can’t pass.

[ljharb]

This shouldn’t use >=, because you can’t guarantee compact with future majors.

Suggested change

	"jest-environment-jsdom": ">=22.0.0"
	"jest-environment-jsdom": "^25.2.0"

[Methuselah96]

I was following the precedent already set by the jest peer dependency in jest-enzyme with using the >=. Should we also change the jest peer dependencies?

[ljharb]

Oof, true enough.

Ideally yes, jest should be using ^22 || ^23 etc, and that should probably match this line.

[ljharb]

However, changing the jest peer dep like that is a breaking change at this point - but so is adding a new peer dep.

[Methuselah96]

In an idealistic world I completely agree with you. However on a more practical level, it's situations like reduxjs/redux-devtools#473 (one example of many in my experience) that cause me to want to be more permissive.

@blainekasten What do you think? What do you want the the peer dependency ranges to be?

[Methuselah96]

@ljharb I made a PR to tighten peer dependency ranges: #344. If that PR gets merged before this one, then I'll gladly update the dependency range here. Otherwise, if this PR gets merged first, then I'll fix it in the other PR.

Since the >= is consistent with the status quo, I think it should be fine for this PR to be merged as-is. Conversation about the version ranges can happen on the other PR.

[ljharb]

I don't think consistency is as important here as getting the range of a new peer dep correct; while it's not up to me, i wouldn't merge it with >=.

[Methuselah96]

@ljharb jest was not in the devDependencies of jest-enzyme, so I was following the precedent set there. I'm fine with adding test dependencies to devDependencies for individual packages, but it looks like we've relied on them being installed as a dev dependency on the monorepo up to this point, so I think that should be a more comprehensive change.

[Whoaa512]

What's the status of this?