fix(eslint-plugin): [consistent-type-definitions] remove fixer when the interface is within a global module declaration #2739
Conversation
…eclaration within TSModuleDeclaration (#2707)
|
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. |
| ':not(TSModuleDeclaration > TSModuleBlock) > TSInterfaceDeclaration'( | ||
| node: TSESTree.TSInterfaceDeclaration, | ||
| ): void { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
…he interface is within a global module declaration
Codecov Report
@@ 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
Flags with carried forward coverage won't be shown. Click here to find out more.
|
|
Should we handle only |
…sue for removing the fixer
…oduleDeclaration without declare or global
| node.parent?.type === AST_NODE_TYPES.TSModuleBlock && | ||
| node.parent.parent?.type === AST_NODE_TYPES.TSModuleDeclaration && | ||
| node.parent.parent?.declare && | ||
| node.parent.parent?.global |
There was a problem hiding this comment.
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.
…g at the grandparent by looking at all the ancestors
fixes #2707