Add autofix to font-weight-notation

[ybiquitous]

Which issue, if any, is this issue related to?

Closes #3158

Is there anything in the PR that needs further explanation?

I've refactored the rule implementation much to support autofix:

• check each value node by the postcss-value-parser module
• unify some logic between the font and font-weight properties (though a few conditional branches remain)
• remove specific logic for the @font-face at-rule

Here is the code outline after the refactoring:

root.walkDecls(/^font(-weight)?$/i, (decl) => {
  const parsedValue = valueParser(getDeclarationValue(decl));

  for (const [index, valueNode] of valueNodes.entries()) {
    // checking each value node...
  }
});

[changeset-bot]

🦋 Changeset detected

Latest commit: 56863de

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
stylelint	Minor

Not sure what this means? Click here to learn what changesets are.

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

[jeddy3]

@ybiquitous This is a fantastic refactor to implement autofix, thank you!

I've thoughts on 3 things:

1. Let's fix our references so they're accurate:

stylelint/lib/reference/keywords.js

Line 31 in efe5283

const fontWeightAbsoluteKeywords = new Set(['bold']);

This set should be: ["normal", "bold"]

And then let's unite the sets in the reference file (rather than the rule itself), e.g.

const fontWeightNonNumericKeywords = uniteSets(
	fontWeightRelativeKeywords,
	fontWeightAbsoluteKeywords,
);

const fontWeightKeywords = uniteSets(
	basicKeywords,
	fontWeightNonNumericKeywords,
	fontWeightNumericKeywords,
);

2. We generally use the format "Expected x to be y" when a rule supports autofixing of small things, e.g. "Expected '400' to be 'normal' (font-weight-notation)".

3. While we're refactoring we may want to remove the validation path, i.e.:

invalidNamed: (name) => `Unexpected invalid font-weight name "${name}"`,

The rule should only be doing one thing.

Shall we do the latter two suggestions in this pull request or in follow-up ones? The latter one may make the refactor even cleaner.

[ybiquitous]

@jeddy3 Thanks for the review! I agree with your suggestions, and I've pushed the first refactoring via 56863de.

I'll work on the remaining suggestions on another PR to clarify the scope of this PR. 💪🏼

[jeddy3]

Thanks for implementing the first suggestion.

PR LGTM. Feel free to merge.

I'll work on the remaining suggestions on another PR to clarify the scope of this PR. 💪🏼

SGTM.