Create `prefer-to-*` rules for `jest-extended`

[SimenB]

There are a bunch of specific rules in https://github.com/jest-community/jest-extended which can be preferred.

I suggest we have rules suggesting their use. So e.g toBeFalse() over toBe(false) etc.

Should be clear in the docs that they are only if you use jest-extended.

/cc @mattphillips

[mattphillips]

Hey @SimenB interestingly I started a new project to do this a week or so ago but haven’t had time to work on it. Check it out here: https://www.github.com/mattphillips/eslint-plugin-jest-extended I was planning on moving it to jest-community once id published it. I’m happy for it to live as part of this plugin though :)

[SimenB]

IMO it's fine to have it as one plugin, as long as it's clearly stated in the docs that the matchers are not part of Jest core.

/cc @thymikee @orta @jkimbo @rogeliog thoughts?

[thymikee]

Hm, I don't know, with separate plugin we can just do:

plugins: ['jest', 'jest-extended']

and have rules easily distinguishable.

[SimenB]

I was thinking of sharing some utils such as

const parsedExpression = utils.parse(node);

if (parsedExpression.isExpect) {
  if (parsedExpression.matcher === 'toBeNull') {}
}

And a bunch of other stuff. I suppose we can publish that as a separate thing though - seems useful for the jasmine plugin as well.

[thymikee]

Or move both plugins to new monorepo eslint-jest?

[SimenB]

Uuuh, yeah that might be the way forward

[thymikee]

But that's just a lot of work with lerna setup probably 😄

[SimenB]

Lerna setup isn't too bad. I also noticed that lerna has built-in conventional commit support now, so we could probably automate a bunch of stuff around it (and maybe bring those learnings back into jest core)

[thymikee]

That would be amazing

[ge65cer]

Follow-up: https://github.com/jest-community/eslint-plugin-jest-extended/issues/2

[G-Rath]

I'm going to resolve this since we've now got eslint-plugin-jest-extended published 🎉