Thanks for the PR, @Andarist!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

Does it hook into default ESLint scope analysis?

We don't hook into it, we define our own which extends the base eslint scope analysis.
The test you modified is a sanity check to ensure we don't break the rule with those changes.

@bradzacher Could u point me to the code lines where this extending takes place? I would be interested in taking a look how u handle that.

https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/parser/src/analyze-scope.ts

tl;dr - we do it pretty poorly right now.
There was a maintainer that was working on it at the start of the year, but they stepped back from the project not long after. Nobody has had the time to pick it up since then.
There is a lot that you have to figure out about how scope analysis works in eslint, as the package that's used (https://github.com/eslint/eslint-scope) is mostly undocumented.
That's the main reason I haven't gone back to finish the work.

As an aside - this is why rules like no-unused-vars, no-use-before-define, etc that rely on correct scope information are broken - because the typescript scope analysis code isn't complete.