Update Rules

[lishaduck]

Some opinionated changes I made. Feel free to close this if you disagree.

• Label configs for debugging in the ESLint Config Inspector.
• Switch off deprecated rules.
• Enable most of the recommended Unicorn rules. (Most controversial commit)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6ca90af

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

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sheriff	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 22, 2024 2:06am

[lishaduck]

Docusaurus's ESM support is a sham!¹ They're just using Jiti, so this PR requires... the dreaded eslint-disable comment: unjs/jiti#101

Footnotes

1. Very much an exaggeration, full of hyperbole: Jiti is certainly ESM, they're just not ESM, we have to be... patient! 😜 ↩

[lishaduck]

Looking back on this, this has some good stuff that could be extracted, but is based on #161, and is heavily conflicted. On top of that, there are definitely some things wrong wtith this approch. I might revist someday, so I'm not closing; there's some context for my future self.

[AndreaPontrandolfo]

i don't understand what is this for. These 2 rules are not in the config.

[lishaduck]

They were in the recommended configs that the config extended.

[AndreaPontrandolfo]

@lishaduck coming back to this, i think we ended up integrating most of the changes here within #326.

About the unicorn changes, it's definitely a change I don't want. I'm pretty happy with how we are handling unicorn rules right now, i want to keep hand-picking them because some of them are extremely opinionated, I don't want to introduce any rule without a specific reason, and some of those rules just don't fit within Sheriff philosophy.

About the config labels, i don't see much of a usecase for them right now, but i'm not opposed about introducing them.

About the deprecated rules, i left a in-code comment.

[lishaduck]

About the unicorn changes, it's definitely a change I don't want. I'm pretty happy with how we are handling unicorn rules right now, i want to keep hand-picking them because some of them are extremely opinionated, I don't want to introduce any rule without a specific reason, and some of those rules just don't fit within Sheriff philosophy.

Yeah, I agree there. I do want to revisit some of them, but I agree we shouldn't extend their recommended config.

About the config labels, i don't see much of a usecase for them right now, but i'm not opposed about introducing them.

They're primarily for the ESLint config inspector, but are generally recommended (the inspector really helps with debugging). I will say that the prefered format is eslint-config-sheriff/someconfigpartname, which I didn't know at the time.

[lishaduck]

Superseded by #331.