refactor: automatically generate the rules-list in README

[MichaelDeBoey]

No description provided.

[MichaelDeBoey]

Seems like some descriptions changed now that we use the rules description directly.

[Belco90]

Nice PR, it's fantastic to automate this process!

Seems like some descriptions changed now that we use the rules description directly.
I would say that's not a problem. Let's leave the new ones and improve them later if necessary (but looks good to me).

One thing I'd like to request is to check the generated rules list in a test similar to how we check it for recommended presets.

[MichaelDeBoey]

One thing I'd like to request is to check the generated rules list in a test similar to how we check it for recommended presets.

Was thinking about this, but not really sure if we should do so and how would be the best to do this 🤔

[Belco90]

Was thinking about this, but not really sure if we should do so and how would be the best to do this 🤔

It could definitely be tricky with the formatting, but we need some way to automate this to avoid getting the rule list outdated. There are 2 options I can think of for now:

1. Add a test to check the rule list generated in a specific branch has the same content as the current rule list. Since we have a placeholder in the README to inject the rule list, we can retrieve the current rule list by regexp using those placeholders. We would have to disable the auto-formatting with prettier in that block.
2. Regenerate the rule list in CI/CD. We would need some workflow to update the rule list if necessary after a change is merged. This could be done by leaving the section empty and injecting the generated rule list in CI/CD in the build step

I prefer option 1 so we have more control about when to generate the rule list, and we also avoid injecting stuff at CI/CD.

[MichaelDeBoey]

Looking at other repos, they don't have anything to test against this.
It's just a thing that needs to be run whenever you create a new rule.
So I wouldn't bother about testing this either tbh 🤷‍♂️

The only thing I would do now is go over all descriptions and see if we want to change them to something more meaningful (like some of them were already in the README list).
This can be done in a separate PR though.

[Belco90]

It's just a thing that needs to be run whenever you create a new rule.

Well, not just when creating a rule, but also when updating or deleting an existing one. Not something critical, but definitely easy to forget about.

Maybe we can add a check to the PR template to indicate "a rule was created/updated/deleted and rule list has been regenerated" or something like that.

[MichaelDeBoey]

Maybe we can add a check to the PR template to indicate "a rule was created/updated/deleted and rule list has been regenerated" or something like that.

Let's create another PR to update our PR template, where we can explain more in depth which things need to be done when creating/updating a rule, ...

[Belco90]

I've created #400 for it.

[Belco90]

I've pointed some descriptions that I think were better before. Can we update those before going ahead?

[Belco90]

Looks ok now, but it's tricky to review if you force-push after changes requested since I can't compare it against my last review 😞

[github-actions]

🎉 This PR is included in version 4.8.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀