Ensure classes beginning with numbers are properly purged

[adamwathan]

Proposed changes

Right now, classes starting with numeric characters are always preserved because of some code that was added to avoid screwing up fractional keyframe values.

This change attempts to solve the keyframe problem in a different way so that classes beginning with numbers can be properly purged.

The current problem comes from this line of code (link):

if (
    SELECTOR_STANDARD_TYPES.includes(type) &&
    typeof value !== 'undefined' &&
    /^\d/g.test(value) === false
) {
    selectorsInRule.push(value)
} else if (

Specifically the regular expression that tests if the selector value begins with a number. As far as I can tell this was added as sort of a hack to detect that what you've parsed is actually part of a keyframe rule, and not a selector. What happens is a value like 99.9% gets run through postcss-selector-parser and comes out as a 99 tag and a 9% class, which is of course not correct because it's not a selector at all.

The regex checks if the value begins with a number as sort of a proxy for figuring out "are we actually doing some pointless parsing on a keyframe rule right now?" which seems reasonable until you remember that a class can actually start with a number too, as long as it's escaped:

<div class="2-panels"></div>

<style>
.\32 -panels { ... }
</style>

Because of this regex, any classes beginning with numbers will always be preserved and never purged.

The change in this PR tries to improve the detection of keyframe rules by adding a guard clause to the top of evaluateRule to check "is the parent of this rule a keyframes at-rule?" and if so, the check is completely skipped.

if (node.parent && node.parent.type === 'atrule' && node.parent.name === 'keyframes') {
    return
}

This lets us remove the regex check completely, so classes beginning with numbers are properly purged.

This issue first showed up when a Tailwind CSS user was using screen prefixes like 400 which led to a ton of classes in their CSS not being removed:

tailwindlabs/tailwindcss#860

I'm not sure exactly how you'd like to organize the tests for this, but for now I've just added a simple additional assertion to an existing test.

I'm also not sure if there are any other consequences to this change that are not covered by the current test suite. As far as I can find, there's no such thing as nested keyframes or anything, so checking if the parent is a keyframes at-rule should be robust enough. I also don't think there's a good reason to evaluate each keyframes child node for any reason because you need to either keep the entire keyframes declaration or throw the whole thing out, not really anything meaningful you can do with the individual children.

Let me know if there's anything I'm not thinking of, thanks!

Types of changes

What types of changes does your code introduce to Purgecss?
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)

[Ffloriel]

Thanks for the detailed PR. I'll review it at the end of the week :)