Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add `whitelistPatternsGreedy` option #424

Merged
merged 1 commit into from Jun 13, 2020

Conversation

@benface
Copy link
Contributor

@benface benface commented May 29, 2020

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
Copy link
Contributor Author

@benface benface commented May 29, 2020

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
Copy link
Member

@Ffloriel Ffloriel commented Jun 13, 2020

LGTM, thanks for the PR

@Ffloriel Ffloriel merged commit adacfd7 into FullHuman:master Jun 13, 2020
2 checks passed
2 checks passed
build (10.x)
Details
build (12.x)
Details
@Ffloriel Ffloriel mentioned this pull request Jun 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.