Consider splitting out a generalized testing plugin

Hi! I’m a big fan of this plugin and have been using it for a while. But I recently switched some projects to Vitest and not all the rules in this plugin apply quite the same in Vitest (e.g. no-jasmine-globals).

eslint-plugin-vitest exists, with some duplication of rule logic. It’s much newer, though, and has fewer rules implemented & a much smaller commmunity.

What do you think about us extracting out the rules from these two plugins into a shared plugin, like eslint-plugin-tests, that’s meant to work for the common style of testing libraries in JS/TS today? I’m a maintainer on typescript-eslint and am confident I can help or lead this if you want. 😄

cc @veritem from eslint-plugin-vitest 👋

[G-Rath]

So I’ve thought about this in the past (especially when I started being involved in maintaining eslint-plugin-jest-dom, among other things), and overall came the conclusion that while it seems like a really good and useful idea on the face, in practice there’s not a whole lot of gain vs the huge potential complexities because of how different core features can be handled in testing frameworks, and that rules typically stabilize very quickly so I wouldn’t expect you would need to be sinking a lot of effort into keeping a copied rule up to date.

This has also been the reason why I’ve not pulled the utilities out into their own package*, because while they look like they’d be useful across a bunch of plugins, everyone has a slightly different implementations which would mean having to get buy-in from the plugin maintainers to potentially refactor their rules heavily, when their existing implementations work fine and generally have a low footprint so it doesn’t feel like there’s a strong enough gain to be worth the effort it’ll require…

So yeah, for me whenever I’ve thought about this I’ve ended up at “this feels like a lot of work for something that doesn’t really fix anything that’s broken”

*: this will probably happen at some point for parseJestFn and friends because eslint-plugin-jest, eslint-plugin-jest-dom, and eslint-plugin-jest-extended should all be resolving jest functions with that, but I’ve got to review eslint-plugin-jest-dom first as that currently uses selectors very heavily.

[mrazauskas]

Programmatic API would be harder to implement, but it would allow more flexibility. For example, "no-deprecated-functions" rule could be build on top of shared logic using framework specific list of deprecated APIs; or having custom rule name would be useful for "jest/no-restricted-jest-methods" and "vitest/no-restricted-vitest-methods" (can be this one is not yet implemented).