[no-restricted-matchers] allow restricting matchers without specific modifier

[d8bauxit8]

Hy guys, I have an issue

If I want to restrict one of matchers except it is negated, I can't tell the config that.

For example: toHaveBeenCalled except not.toHaveBeenCalled

Can you add this little feature to no-restricted-matchers rule?

[G-Rath]

Yeah, I mentioned this when I implemented the rule:

This rule lets you ban *.modifier.matcher & *.matcher but not expect.matcher. The ability to ban just modifier.matcher comes naturally, but I couldn't come up with a nice way of letting you ban only a matcher without any modifiers; in saying that I don't think there's a lot of gain in being able to do that.

I was sort of hoping no one would ask so I wouldn't have to decide on an actual solution, but you have so guess it's time to bite the bullet 😅

In hindsight it might have been better to make matcher only restrict matcher and then either people just have a line for each modifier if they want (optionally we could have had an anyModifier: true option).

(that actually does sound like a good idea - @SimenB fyi I might do this in our next major)

For now I think it's probably easiest to take an object with a allowedModifiers array property (+ a message property):

type RestrictedMatcher = RestrictedMatcherConfig | RestrictedMatcherConfig['message'];
interface RestrictedMatcherConfig {
  message: string | null;
  allowedModifiers: string[];
}

[d8bauxit8]

Oh, sorry I didn't read that. 😬

This sounds good. 👌

Btw if this feature is done, I think, the prefer-called-with rule will be unnecessary because we can add those logics into this config. 😃

{
    "toHaveBeenCalled": {
        message: "Use `toHaveBeenCalledTimes` (and `toHaveBeenCalledWith` if it is necessary) instead",
        allowedModifiers: ["not"]
    },
    "toBeCalled": {
        message: "Use `toBeCalledTimes`  (and `toBeCalledWith` if it is necessary) instead",
        allowedModifiers: ["not"]
    }
}

What do you think about? 👀

[G-Rath]

Oh, sorry I didn't read that. 😬

All good, I wasn't expecting you to go digging around PRs - I mentioned it just as a tie-in and reminder to myself :)

What do you think about? 👀

Yeah we probably could - I'm on the fence about actually doing that though because I think that the situation is a good one and by having a specific rule you can more easily enable it in shared configs (the rules I axed with no-restricted-matchers were purely stylistic).

[github-actions]

🎉 This issue has been resolved in version 27.0.0-next.2 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 27.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[SimenB]

@G-Rath is this totally solved?

[G-Rath]

@SimenB yup, not sure why it didn't get closed by GitHub