refactor: use regexp-groups to simplify ignores

[ST-DDT]

Implement idea suggested here: #2773 (comment)

• feat(no-deprecated-slot-attribute): regex ignore patterns #2773 (comment)

---

Excluding/Ignoring things is a common task in rules. This PR creates a helper that hides all the string[] -> regexp[] -> boolean logic in a simple helper function.

const options = context.options[0] || {}
const { ignore = [] } = options
const ignoreGroupMatcher = regexp.toRegExpGroupMatcher(ignore)

...

 if (
  ignoreGroupMatcher(
    componentName,
    casing.pascalCase(componentName),
    casing.kebabCase(componentName)
  )
) {
  // skip
  return
}

The current project contains at least 9 instances of .map(toRegExp) + a few more using more verbose syntax.

If the general design of this feature is accepted, I will convert the other locations to the new feature and mark this PR as POC.

I'm not super happy with the method name and jsdocs, so any input would be appreciated.

[changeset-bot]

⚠️ No Changeset found

Latest commit: b56eec9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[FloEdelmann]

I like the idea! It would be great to see it used a lot more in the whole codebase 🙂

[ST-DDT]

I like the idea! I would be great to see it used a lot more in the whole codebase 🙂

Does that count as

the general design of this feature is accepted

so that I should start converting the rest of the applicable locations?

[FloEdelmann]

I should start converting the rest of the applicable locations?

That would be great! Do you want to want to give it a go?

[ST-DDT]

Ready for review/merge.

There are a few locations left, that either use plain string[] ignore lists or just use a single ignore pattern, that I haven't touched, but I think they can be enhanced in later PRs on demand.

[FloEdelmann]

Very cool, thank you! 🙂
Looks good to me now.

There are a few locations left, that either use plain string[] ignore lists or just use a single ignore pattern, that I haven't touched, but I think they can be enhanced in later PRs on demand.

Would you like to submit a follow-up PR for this? That would be awesome! 🚀

[FloEdelmann]

Don't be surprised, I'll try out the Copilot reviewer feature now 😄

[waynzh]

LGTM! Thank you!

[Copilot]

Pull Request Overview

This PR introduces a new helper toRegExpGroupMatcher to streamline ignore/allow logic by consolidating multiple string[] → RegExp[] → boolean patterns into a single matcher function. It also extends toRegExp to accept flag additions/removals and refactors existing rule files to use the new helper.

• Adds toRegExpGroupMatcher and updates toRegExp signature in lib/utils/regexp.js
• Replaces many .map(toRegExp) and custom buildMatcher usages in rule files with toRegExpGroupMatcher
• Adds comprehensive tests for both toRegExp and toRegExpGroupMatcher

Reviewed Changes

Copilot reviewed 20 out of 20 changed files in this pull request and generated 1 comment.

File	Description
tests/lib/utils/regexp.js	Expanded tests for toRegExp and new toRegExpGroupMatcher
lib/utils/regexp.js	Added toRegExpGroupMatcher, enhanced toRegExp with flag handling
lib/rules/*	Refactored ignore/allow patterns to use toRegExpGroupMatcher and removed custom matcher logic

Comments suppressed due to low confidence (2)

lib/utils/regexp.js:56

• The JSDoc for toRegExpGroupMatcher could be expanded to note that input patterns may be regex-like strings (e.g., '/^foo/i') and that flags are handled by the underlying toRegExp helper.

 * Converts an array of strings to a singular function to match any of them.

lib/utils/regexp.js:62

• [nitpick] The name 'toRegExpGroupMatcher' is quite verbose; consider a shorter, more intention-revealing name (e.g., 'matchAnyPattern' or 'anyPatternMatcher') to improve readability.

function toRegExpGroupMatcher(patterns = []) {

[FloEdelmann]

Should we mention refactorings in the changelog? If no, then no changeset is necessary.

[waynzh]

Should we mention refactorings in the changelog? If no, then no changeset is necessary.

Make sense to me, users don’t really care about internal code shuffling, so we don’t need to include it.