feat(no-restricted-matchers): match based on start of chain, requiring each permutation to be set #1218
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
G-Rath
force-pushed
the
adjust-no-restricted-matchers
branch
2 times, most recently
from
8ecfbac to
8af432d
Compare
…g each permutation to be set BREAKING CHANGE: `no-restricted-matchers` now checks against the start of the expect chain, meaning you have to explicitly list each possible matcher & modifier permutations that you want to restrict
G-Rath
force-pushed
the
adjust-no-restricted-matchers
branch
from
8af432d to
e6d9ea7
Compare
github-actions bot
pushed a commit
that referenced
this pull request
Aug 28, 2022
# [27.0.0-next.2](v27.0.0-next.1...v27.0.0-next.2) (2022-08-28) ### Bug Fixes * **unbound-method:** don't suppress errors from base rule ([#1219](#1219)) ([7c1389e](7c1389e)) ### Features * make `no-alias-methods` recommended ([#1221](#1221)) ([914b24a](914b24a)) * **no-jest-import:** remove rule ([#1220](#1220)) ([918873b](918873b)) * **no-restricted-matchers:** match based on start of chain, requiring each permutation to be set ([#1218](#1218)) ([f4dd97a](f4dd97a)) ### BREAKING CHANGES * `no-alias-methods` is now recommended as the methods themselves will be removed in the next major version of Jest * **no-jest-import:** removed `no-jest-import` rule * **unbound-method:** errors thrown by the `unbound-method` base rule are no longer suppressed - really this means that if you don't specify `project` when this rule is enabled and `@typescript-eslint/eslint-plugin` is present, that error will no longer be suppressed instead of silently doing nothing; it will still not throw if this rule is enabled without the base rule being present * **no-restricted-matchers:** `no-restricted-matchers` now checks against the start of the expect chain, meaning you have to explicitly list each possible matcher & modifier permutations that you want to restrict
|
🎉 This PR is included in version 27.0.0-next.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
github-actions bot
pushed a commit
that referenced
this pull request
Aug 28, 2022
# [27.0.0](v26.9.0...v27.0.0) (2022-08-28) ### Bug Fixes * **unbound-method:** don't suppress errors from base rule ([#1219](#1219)) ([7c1389e](7c1389e)) ### Features * drop support for `eslint@6` ([#1212](#1212)) ([21fc2fe](21fc2fe)) * drop support for Node versions 12 and 17 ([#1211](#1211)) ([4c987f5](4c987f5)) * make `no-alias-methods` recommended ([#1221](#1221)) ([914b24a](914b24a)) * **no-jest-import:** remove rule ([#1220](#1220)) ([918873b](918873b)) * **no-restricted-matchers:** match based on start of chain, requiring each permutation to be set ([#1218](#1218)) ([f4dd97a](f4dd97a)) ### BREAKING CHANGES * `no-alias-methods` is now recommended as the methods themselves will be removed in the next major version of Jest * **no-jest-import:** removed `no-jest-import` rule * **unbound-method:** errors thrown by the `unbound-method` base rule are no longer suppressed - really this means that if you don't specify `project` when this rule is enabled and `@typescript-eslint/eslint-plugin` is present, that error will no longer be suppressed instead of silently doing nothing; it will still not throw if this rule is enabled without the base rule being present * **no-restricted-matchers:** `no-restricted-matchers` now checks against the start of the expect chain, meaning you have to explicitly list each possible matcher & modifier permutations that you want to restrict * Support for ESLint version 6 is removed * Node versions 12 and 17 are no longer supported
|
🎉 This PR is included in version 27.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
@G-Rath, before creating an issue. I feel like this change has unintended side effects. With the following item in the map we're also getting errors on |
|
@cascornelissen yeah that's a bug - create an issue and I'll try to get to it in the morning |
1 task
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
BREAKING CHANGE
Resolves #1156
This messed my head up a little trying to come up with an intuitive interface that let you shortcut the config a bit i.e. by allowing
****, but it always came out feeling brittle and hard to explain or dropping support for restricting modifiers; in the end I realised changing the check to just bestartsWithgets us what we want while being easy to understand.