Feature Request: Make this plugin work with bun

[TkDodo]

Feature Request: Make this plugin work with bun

[SimenB]

I have no interest in maintaining a comparison table (or changing default behaviour). But an option to allow people to mix and match seems fine as long as we state no compat promises are made

[SimenB]

I don't wanna hard code in bun stuff, but happy to take a PR that makes @jest/globals as import source configurable.

A caveat is that there's no guarantee the semantics this plugin assumes holds when using bun instead (I've not used it at all, and I didn't know it lifted its test API from Jest). But yeah, making the import name configurable seems reasonable to me regardless 🙂

[TkDodo]

what the bun test runner does is trying to be a drop-in replacement for jest & vitest; so even if you have an import from @jest/globals, if you run the test with bun, it will swap it out internally. Same for vitest.

but happy to take a PR that makes @jest/globals as import source configurable.

thank you, I'll try to take a stab it at. Am I assuming correctly that '@jest/globals' should be the default for that option, and that it should be an Array of strings? Or is a single string resource enough (I would guess it is ..)

[G-Rath]

I'm not too thrilled about this because we're meant to be just for Jest but I guess supporting a setting for it wouldn't hurt though

even if you have an import from @jest/globals, if you run the test with bun, it will swap it out internally

Doesn't that mean you can just import from @jest/globals and everything will work? in my eyes that's better anyway because you're saying "I want the Jest API" - the fact that Bun provides its own Jest-API-compatible module is an implementation detail.

I'd also be interested in hearing from @JoshuaKGoldberg on if this would help with #1289 - my understanding is vitest is also meant to be a drop-in replacement for Jest so in theory this new setting should help but they're already reported that not all rules are 1:1 compatible

[TkDodo]

Doesn't that mean you can just import from @jest/globals and everything will work? in my eyes that's better anyway because you're saying "I want the Jest API" - the fact that Bun provides its own Jest-API-compatible module is an implementation detail.

Yes, you can, but then we'd need an additional dependency on @jest/globals and add the types as well. I don't really prefer the "interop mode". I also think that some rules are not really jest specific, like no-focused-tests is something I definitely need no matter the test framework to avoid accidentally committing a test I had focussed on during development.

the suggested eslint-plugin-tests sounds very interesting in that regard.

I'm not too thrilled about this because we're meant to be just for Jest but I guess supporting a setting for it wouldn't hurt though

I can totally live with the patch we have right now, so let's take the time to settle on the right solution before introducing a new api :)

[JoshuaKGoldberg]

I'd also be interested in hearing from @JoshuaKGoldberg on if this would help with #1289

Yeah that'd be great 😄 but for the mentioned caveats that the various testing libraries are all at least a little different from each other. Maybe it'd be useful to have a big comparison table of all the differences & similarities? (not volunteering myself, sorry)