feat(eslint-plugin): add new rule require-super-ondestroy

[markoblagdan]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngrx/platform/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[x] Code style update (formatting, local variables)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[x] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

No message from ESLint when overriding ngOnDestroy() in a class extending ComponentStore from @ngrx/component-store and not calling the parent's method via super.ngOnDestroy().

Closes #4505

What is the new behavior?

Running eslint or opening the relevant class file in an editor supporting ESLint shows an error message when overriding ngOnDestroy() in a class extending ComponentStore and not calling the parent's method via super.ngOnDestroy().

Does this PR introduce a breaking change?

[ ] Yes
[x] No

[netlify]

✅ Deploy Preview for ngrx-io ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	c0fb1d3
🔍 Latest deploy log	https://app.netlify.com/sites/ngrx-io/deploys/675769cd4d979100083df5be
😎 Deploy Preview	https://deploy-preview-4611--ngrx-io.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 configuration.

[markoblagdan]

Maybe I should've mentioned the following in the PR under Other information, wasn't sure:

• I do not handle the case when ComponentStore is a custom class not imported from @ngrx/component-store, which means this rule will raise a false error if one extends from a custom ComponentStore class and overrides ngOnDestroy. Seemed like a weird edge case so I did not handle it, but let me know if it would be better to do so anyway
• considered adding a fixer function, but I did not find a good way to handle varying user and editor tab settings, so automatically writing the required line in say, the last line of the overriden method, would mess up formatting

Additional changes unrelated to #4505 (not sure if it was OK to include this):

• added a new util function for the component-store rules, getNgrxComponentStoreNames, and used it where appropriate
• removed deprecated method call context.getSourceCode() and replaced it with the suggested context.sourceCode property
• removed a line in ng-add schema.ts which disables the @typescript-eslint/no-empty-interface rule

[timdeschryver]

Thanks @markoblagdan !

[amakhrov]

this uses :has - which is technically supported by the underlying esquery, but is not officially supported by eslint. It's not mentioned in the docs here, and also see this issue: eslint/eslint#14076 (comment).

do you think this approach is reasonably future-proof?

[markoblagdan]

I was not aware of this - doesn't seem like support for it would be dropped, but maybe it's safer to use another approach.

@timdeschryver If I wanted to make a PR with an alternative to using :has, what would be the best way - should we create a new issue and I make a bugfix PR referencing it, or some other way?

[timdeschryver]

I prefer to keep it as-is.
There are multiple rules using :has, and I like it because it's easy to read.
If it does become deprecated/removed in the future we can update it.