feat(rome_js_analyze): Implement noStaticOnlyClass

[nikeee]

Summary

This is a WIP PR. Things need to be done better (for example, that match block with a lot of repeated code). I'm takign suggestions here. :)

Things to clarify:

• What is JsBogusMember?
• What about TsConstructorSignatureClassMember? It seems as if we can return false here (and thus, treat it as non-static).
• I'm not sure about the wording of the diagnostic.
• Does this rule match on class expressions or default class exports?
• What about private-static fields (static #foo)? For unicorn, these seem valid: https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/no-static-only-class.md

Notes:

• The diagnostic is located at the class name, not the entire class (for less visual noise).
• In case the class is anonymous, the diagnostic is located at the class keyword. This may be removed, if we decide to exclude anonymous classes from this rule.

Resolves #4482

Test Plan

Some tests are there. We need to check whether this is everything needed.

Changelog

• The PR requires a changelog line - I'll do one if the PR gets in a more finished state

Documentation

• The PR requires documentation
• I will create a new PR to update the documentation (if necessary, please comment)

[netlify]

✅ Deploy Preview for docs-rometools ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	d6744cf
🔍 Latest deploy log	https://app.netlify.com/sites/docs-rometools/deploys/64871e5b09b4df0008e23ab4
😎 Deploy Preview	https://deploy-preview-4514--docs-rometools.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Conaclos]

Thanks for your contribution :)

What about private-static fields (static #foo)?

What about TsConstructorSignatureClassMember? It seems as if we can return false here (and thus, treat it as non-static).

I think you got them right: we should treat them like other constructs.

Does this rule match on class expressions or default class exports?

Both.

The disuccsion that I had with ematipico in #4482 has certainly confused you: The rule will be in style once stabilized (in several versions from teh current one). Any new rules should be a nursery rule.

Your rule should be placed in analyzers/nursery (semantic_analyzers is reserved for rules that use the semantic model).

[nikeee]

I just noticed that the rule also matches on empty classes. I've decided to skip empty classes, since it might be the case that the user is currently typing out a new class. If this doesn't match the intentions of this rule, feel free to comment.

Any Idea on how to get rid of the code duplication? I don't think it's that bad, but it doesn't seem right.

[ematipico]

Thank you for you contribution!

[ematipico]

@Conaclos could you review the PR please? I believe we can merge it?

@nikeee Would you mind rebasing your branch? So we can merge it ;)

[nikeee]

@ematipico done and ready for squash :)

[Conaclos]

Thanks for your contribution :)