Very, very many errors have the overly broad `solid/reactivity` name

[danieltroger]

Context

I'm working with solid-js in a part of our product.
None of my colleagues know solid-js apart from knowledge sharing sessions that I have hosted. They are react devs and the rest of our product is react.
I added this eslint plugin so they get some help and guardrails when they write solid-js (which mainly happens when I'm on vacation).

Because they probably don't have their IDEs configured to work with ESLint correctly, I have added a CI step that will fail if there are any eslint warnings (making them check out the errors when merging a PR).

Painpoint

However, my problem is that there's a lot of noise from the solid eslint plugin that I wouldn't want the PRs to fail on (and I don't want to litter the whole codebase with // eslint-disable-next-line solid/reactivity).

Proposed solution

1. Some of the things from this package should be errors instead of warnings, seems right now like everything is warnings?
2. There should be more granual descriptions for lint messages from this plugin. every error message should have it's own name, like solid/reactivity. This way I could just disable all warnings in my eslint config that essentially say "sorry now you're on your own because you didn't do this in an easily lintable way", but still get helpful warnings where the plugin is actually certain I'm doing something wrong.

Examples where this would help

No point in capturing the memo in a variable here

---

Signals are saved in a set here, I do not want to destructure and then put it together to an array again

---

The signal is passed down to a function, no reason to pass a getter and a setter when I can just pass the whole signal

---

The eslint plugin is just generally lost here it seems

---

I know what I'm doing and am fine because I do not access any reactive getters after the await, and this code is still much cleaner IMO than wrapping the async part in an IIFE

---