fix(eslint-plugin): [consistent-type-definitions] remove fixer when the interface is within a global module declaration

[ddubrava]

fixes #2707

[typescript-eslint]

Thanks for the PR, @ddubrava!

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.

[bradzacher]

this will stop the rule reporting at all when an interface is within a module declaration.
Which is too wide of a change.

Instead, we still want to report on interface within a module declaration - but we want to just no automatically fix it if and only if it's within a declare global

[ddubrava]

What's the manual fix for that case? I thought it's impossible to use the type within a declare in the case so we have to turn off it completely

[bradzacher]

the manual fix in that case would be for the engineer to review the lint and disable it in that case.

it's impossible for us to tell exactly what the intentions are so we have three options:

• report with a fixer
  • this is bad because it means we can break the user's code.
• do nothing
  • this isn't great because it means that the user can easily create code which should be marked as invalid.
  • it's impossible to tell if the code was written invalidly because it HAD to be this way, or if the author just wrote it wrong.
• report without a fixer
  • this is a best-of-both worlds.
  • if the code is actually invalid - the user can fix it
  • if it's an edge case - the user can suppress the lint rule to show it's intentionally written this way.

I thought it's impossible to use the type within a declare in the case so we have to turn off it completely

Nope - it's perfectly acceptable to use type declarations or interface declarations.
In some cases the latter is better as it will allow specifically for augmentation via declaration merging.

[codecov]

Codecov Report

Merging #2739 (4d14d68) into master (e82698c) will increase coverage by 0.00%.
The diff coverage is 92.85%.

@@           Coverage Diff           @@
##           master    #2739   +/-   ##
=======================================
  Coverage   92.79%   92.80%           
=======================================
  Files         297      300    +3     
  Lines        9833     9852   +19     
  Branches     2762     2767    +5     
=======================================
+ Hits         9125     9143   +18     
  Misses        332      332           
- Partials      376      377    +1     

Flag	Coverage Δ
unittest	92.80% <92.85%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...nt-plugin/src/rules/consistent-type-definitions.ts	91.17% <92.85%> (+0.85%)	⬆️
packages/eslint-plugin/src/rules/array-type.ts	97.33% <0.00%> (-1.30%)	⬇️
packages/scope-manager/src/lib/index.ts	100.00% <0.00%> (ø)
packages/scope-manager/src/lib/es2020.ts	100.00% <0.00%> (ø)
packages/scope-manager/src/lib/esnext.ts	100.00% <0.00%> (ø)
packages/visitor-keys/src/visitor-keys.ts	100.00% <0.00%> (ø)
...ackages/eslint-plugin/src/rules/no-implied-eval.ts	93.75% <0.00%> (ø)
...ckages/eslint-plugin/src/rules/no-throw-literal.ts	95.00% <0.00%> (ø)
...ckages/scope-manager/src/lib/webworker.iterable.ts	100.00% <0.00%> (ø)
...kages/scope-manager/src/lib/es2020.sharedmemory.ts	100.00% <0.00%> (ø)
... and 2 more

[ddubrava]

Should we handle only declare global {} or global {} is also shouldn't be fixed? And what about not global declarations?

[bradzacher]

instead of just looking at the grandparent - we could instead look at all the ancestors so we can catch cases like:

declare global {
  namespace Foo {
    interface Bar {}
  }
}

context.getAncestors() will return you an array and you can traverse it from the start to go from the highest parent.

[bradzacher]

LGTM - thanks for this!