Update stylelint@latest and @primer/stylelint-config@latest

[jonrohan]

This upgrades @primer/stylelint-config@latest which changes out the no-unsupported-browser-features with browser-compat.

I also adjusted the lint script to suppress warnings and to report needless disables.

Rollout strategy

• Patch release
• Minor release
• Major release; if selected, include a written rollout or migration plan
• None; if selected, include a brief description as to why

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9df1d45

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[github-actions]

👋 Hi, this pull request contains changes to the source code that github/github depends on. If you are GitHub staff, we recommend testing these changes with github/github using the integration workflow. Thanks!

[github-actions]

size-limit report 📦

Path	Size
packages/react/dist/browser.esm.js	97.68 KB (0%)
packages/react/dist/browser.umd.js	97.81 KB (0%)

[joshblack]

Could we still use --max-warnings=0 here, as well? Just to fail on if warnings are being reported. To me this can help out a lot with avoiding the problem where linting emits a ton of warnings over time and can also catch some helpful things, as well, for warnings that should have been errors.

[jonrohan]

We use the warnings in the config to let people know of minor issues but not blockers. Adding the max warnings 0 fails on everything which isn't how dotcom behaves

[joshblack]

@jonrohan my preference would definitely be to treat the warnings as errors. If it's not worth failing the build on, then it is adding some noise that can build up over time when linting. This can make it more difficult to track down the specific error you're running into 😞 I've been running into this a little bit this past week on the dotcom side of things with eslint which is why it's top of mind.

Would there be a downside to having to address the warnings on our end?

[jonrohan]

@joshblack The 2 rules we change to warnings are browser-compat and value-no-unknown-custom-properties

https://github.com/primer/stylelint-config/blob/4be05424a07ef6567740ff851fcd4bb9b3f9123c/index.js#L85
https://github.com/primer/stylelint-config/blob/4be05424a07ef6567740ff851fcd4bb9b3f9123c/index.js#L45

• browser-compat will warn folks when they're using features that haven't fully shipped to all browsers in our browserslist config yet.
• value-no-unknown-custom-properties will warn folks when they're using a css property that isn't defined in the page or in primer/primitives.

Both of these as configured will only show up as squiggly yellow underlines in editors. Which also can be configured to ignore warnings. The CI will never fail on these. If you feel strongly these should be errors we should instead change their warning level. We intentionally changed them to warnings in the beginning because we knew that value-no-unknown-custom-properties will probably have a lot of false positive errors because it can't know how the page is put together. browser-compat we made a warning because there's often progressive enhancements built into CSS and we didn't want to get in the way.

IMO failing the build on warnings is counter intuitive because we're making warning and error the same thing. If someone sees that their build ❌ and then it says "warning: stylelint browser-compat` they will be confused.