[Feature] Release version with Jest 28

[IanVS]

Now that the test-runner will soon support jest 28, it would be great to have a new version of @storybook/jest (and @storybook/expect) that also use jest 28 as well, to avoid the problems that jest 27 has with using global, making it difficult to run in the browser.

[KubaJastrz]

Can we include this in Storybook 7.0? Test-runner has already been updated to support Jest 28. Do you need any help?

[itsezc]

Is there any workaround in the mean time until we wait for an update?

[IanVS]

I've opened storybookjs/expect#12. This @storybook/jest package is really just a re-export of that one, plus jest-mock. So, I think expect needs to come first. But @yannbf will likely need to be the one to shepherd it through, since it seems like a bit of a delicate dance.

[IanVS]

Thanks for pushing storybookjs/expect#12 across the line, @ghengeveld! What remains to do here to pull it in?

In the meantime, I suppose we can use overrides in our package.json to start using it and testing it out (pun intended).

[yannbf]

Hey @IanVS! There were some issues in that version which we fixed (jest-util is not that browser friendly), so we made a v28.1.3 release that behaves fine (as far as I tested it), however there are some other questions remaining:

• if we update @storybook/jest to use @storybook/expect@28.1.3, we likely need to update jest-mock too. I'm not sure about the implications of that upgrade.
• we should probably do a "jest 28" release in @storybook/jest, likely 0.2.0, then a "jest 29" release for @storybook/expect + @storybook/jest 0.3.0, but once again I'm not sure about the upgrade implications.
• addon-interactions uses jest-mock 27 as a direct dependency, will that clash somehow? given that it's tied to the monorepo, we can't make a breaking change to upgrade it.
• what exactly is the benefit of making the upgrade, and how can we see that benefit? The original problem reported in this issue does not exist anymore, as it's been fixed here, so you don't really need the preview-head workaround anymore. I also remember trying expect 28 and expecting (no pun intended) to not need the preview-head workaround, but that was not the case. It was still broken, which is why I made that fix I just referred.

[IanVS]

You bring up good points, I'll give it some thought. Off the cuff, I'll say that I see the global polyfill as a workaround, not a permanent solution. Vite does not polyfill node globals, so therefore right now it's possible for stories to work fine if they use global, but the app could break because it doesn't have the same polyfill that storybook is adding hidden behind the scenes.

I did try using an override, and indeed I found trouble with the test-runner, though I wasn't able to track it down to where exactly it came from.

addon-interactions uses jest-mock 27 as a direct dependency, will that clash somehow? given that it's tied to the monorepo, we can't make a breaking change to upgrade it.

That's too bad, I wish we would have taken care of this before storybook 7's release. I was quite looking forward to removing the global polyfill for vite storybook, and I was under the impression that the reason we weren't really prioritizing these satellite repos was that we would be able to take care of them after the 7.0 launch. Hopefully we can figure all of this out for 8.0.

[IanVS]

I guess this can be closed, now that 0.2.0 includes jest 28, right?

[kasperpeulen]

It still uses 27 from jest-mock, we tried to upgrade it, but it breaks browser compatibility.

[IanVS]

@kasperpeulen it looks like it also uses @storybook/expect version 27.5.2-0, even though @types/jest has been updated to 28.1.3. Isn't that a potential issue?

[yannbf]

@IanVS The new version of this library will update @storybook/expect to 28.1.3!

[IanVS]

🙌 Now we just have to figure out jest-mock, I guess.

[IanVS]

For now, when I need mocks, I'm using jest-mock 28 directly, and using:

import { ModuleMocker } from 'jest-mock';

const mock = new ModuleMocker(window);

And that's working fine in my stories.