feat: no-invalid-properties rule

[nzakas]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request?

Create a new no-invalid-properties rule.

What changes did you make? (Give an overview)

• Moved logic from no-unknown-properties into no-invalid-properties
• Moved logic from no-invalid-property-values into no-invalid-properties
• Added tests for no-invalid-properties
• Added docs for no-invalid-properties
• Removed old code for no-unknown-properties and no-invalid-property-values

Related Issues

Refs #9

Is there anything you'd like reviewers to focus on?

[eslint-github-bot]

Hi @nzakas!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the pull request title to match this format, as we use it to generate changelogs and automate releases.

• The commit message tag wasn't recognized. Did you mean "docs", "fix", or "feat"?
• There should be a space following the initial tag and colon, for example 'feat: Message'.
• The first letter of the tag should be in lowercase

To Fix: You can fix this problem by clicking 'Edit' next to the pull request title at the top of this page.

Read more about contributing to ESLint here

[jeddy3]

Merging the rules looks good. It avoids that unnecessary check and means you can choose to add syntax customisation at either the rule or language level.

I think the rule currently checks both property declarations and descriptor declarations rather than just property ones.

You may want to add valid tests for:

• @font-face { font-weight: 100 400 }
• @property --foo { syntax: "*"; inherits: false; }

As I think it'll incorrectly flag:

• 100 400 as an invalid value because the font-weight property accepts <font-weight-absolute> | bolder | lighter whereas the font-weight descriptor accepts <font-weight-absolute>{1,2}
• syntax and inherits as (unknown) properties because they are descriptors

[nzakas]

I think the rule currently checks both property declarations and descriptor declarations rather than just property ones.

Ah, nice catch! I didn't realize the same node type was used in both cases.

[mdjermanovic]

LGTM, thanks!