#697@patch: Upgrade jest dependencies to 29.4.0.

[ahuth]

Fixes #697 by upgrading all jest dependencies (especially the ones in @happy-dom/jest-environment) to 29.4.0.

I also verified that @happy-dom/jest-environment works when being used in Jests v27 and v29.

[jereklas]

In my opinion this should have been solved in a different way. I would have preferred this just become a series of peerDependencies, instead of dependencies. You would then update the installation steps to be the following.

yarn add --dev @happy-dom/jest-environment @types/jest @jest/environment @jest/fake-timers jest-mock jest-util

There's nothing in the class that really cares about what versions of jest is being used. So why force users to a particular jest version just to use happy dom? Thoughts @ahuth?

Note: This still working with jest 27 is maybe just a happy coincidence (it means someone running jest 27 is using jest 29 for the other packages which might not work for all aspects of jest but 99%), but will probably result in it breaking again on Jest 30, where peerDependencies will probably "just work" as consumers would update all of their jest dependencies as they increment versions.

[jereklas]

@jest/types shouldn't be a dependency, it needs to be a devDependency so that it's not installed for end users of the package (it's only here for type information).

[jereklas]

same goes for @jest/environment?

[capricorn86]

@jereklas I think @jest/environment has to be a dependency here. @jest/types can be a dev dependency.

[ahuth]

There's nothing in the class that really cares about what versions of jest is being used. So why force users to a particular jest version just to use happy dom?

I see where you're coming from, @jereklas. But I don't think peer deps makes sense here.

To use Jest I'd expect to have to install

1. Jest
2. maybe @types/jest
3. a jest environment (node, jsdom, or happy-dom).

Not the fake timers, mocking, utils, other jest sub-packages, etc.

In fact, both jest-environment-node and jest-environment-jsdom have dependencies on the same libraries. So I think it makes sense that @happy-path/jest-environment does as well.

Maybe it would be clearer if @happy-dom/jest-environment had the same major version number as the version of Jest it worked with. Or at least if updating Jest to a new major version here was a breaking change.

Note: This still working with jest 27 is maybe just a happy coincidence

For sure. Definitely a possibility that a future version of Jest breaks it. Or even just being mismatched (using jest v27 but jest-mock v29) is a bit weird (even if it works currently).

[jereklas]

I guess chalk it up to a difference of opinion of how dependencies are managed. At the end of the day, I have a workaround irrespective of how this gets resolved that can allow me to have all versions of the packages align to exactly the versions I want (using pnpm to override what the package.json file says to install).

Below are a continuation of my opinion, feel free to skip over if you'd like :)

I would much rather be told to install 2-3 more things upon installation so that I have control over keeping everything used by my tooling version aligned, then hope for everything to "magically" work today while all versions are aligned, and then fail tomorrow when they're no longer aligned.

To continue my concerns, updating to ^29.4.0 and working with 27.x.x is "working" only because the v28 and v29 versions support enough of the ModuleMocker, jest-util, LegacyFakeTimers, and ModernFakeTimers APIs. Without reading and understanding everything that's changed in Jest between 27 and 29, I cannot say without a doubt that having version 27 of Jest installed in an environment and this package using version 29 of the auxiliary packages means that everything a user could use in Jest is actually supported with the happy-dom jest environment.

This just speculation, but I wouldn't be surprised at all if 90% of Jest usages just work with Jest 27.x.x being used with the 29.x.x support packages, but then there could be ~10% of Jest that flat out fail, and those users will be stuck wondering why this package doesn't work.

All of the above happens because people don't actually know what their dependencies are, and having someone install more of them while slightly a pain, at least makes everything less "magic".

[capricorn86]

@jereklas @ahuth it happens that Jest changes how the environment is implemented. It has happened a couple of times in the past.

One solution would be to split out @happy-dom/jest-environment to its own repo and use the same versions as Jest for the package. Then happy-dom can be a peer dependency instead as there are less dependencies towards how Happy DOM is implemented compared to Jest here.

Maybe this should be handled in a separate ticket in that case? I have created #703 for it.

[ahuth]

One solution would be to split out @happy-dom/jest-environment to its own repo and use the same versions as Jest for the package. Then happy-dom can be a peer dependency instead as there are less dependencies towards how Happy DOM is implemented compared to Jest here.

👍 Makes sense to me