Add whitelistPatternsGreedy option

[benface]

Proposed changes

I am proposing a new whitelistPatternsGreedy option, similar to the existing whitelistPatterns and whitelistPatternsChildren options, but that whitelists an entire selector if any part of the selector matches the regex.

If you have a selector like this:

.my-module.color--blue {}

And my-module is found by the extractor but not color--blue, no combination of the current whitelistPatterns / whitelistPatternsChildren exists that would prevent this selector from being purged.

With whitelistPatternsGreedy, you could whitelist this selector (and any other that contains the my-module class) like this:

{
  whitelistPatternsGreedy: [/^my-module$/],
}

The reason I would like to add this feature is that I'm looking for a way to whitelist all scoped CSS in Vue, regardless of whether the classes are found in the HTML or not:

<template>
  <div :class="`size--${size}`"></div>
</template>

<style scoped>
  .size--small {
    font-size: 12px;
  }
  .size--large {
    font-size: 18px;
  }
</style>

Due to the dynamic class attribution (size--${size}), the size--small and size--large classes would normally be purged with the following config:

{
  whitelistPatterns: [/data-v-.*/],
  defaultExtractor: (content) => {
    const contentWithoutStyleBlocks = content.replace(/<style[^]+?<\/style>/gi, '');
    return contentWithoutStyleBlocks.match(/[A-Za-z0-9-_:/]+/g) || [];
  },
}

Of course, we could opt to not remove the <style> blocks from the extracted content and it would also fix the issue here, but I like having that to prevent uselessly keeping Tailwind utility classes that are only used with @apply. So instead, we can replace whitelistPatterns with whitelistPatternsGreedy and any selector that contains a data-v-* attribute will be whitelisted.

Thank you!

Types of changes

What types of changes does your code introduce?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

[benface]

If you have a selector like this:
.my-module.color--blue {}
And my-module is found by the extractor but not color--blue, no combination of the current whitelistPatterns / whitelistPatternsChildren exists that would prevent this selector from being purged.

I just realized that this is not exactly true: whitelistPatternsChildren would actually work here but I would consider it a bug because if you switch the classes in the selector (so .color--blue.my-module) then it wouldn't work because it would look up color--blue first, see that it is not found in the extracted selectors, and automatically purge the rule. I don't think the class order should matter.

[Ffloriel]

LGTM, thanks for the PR