Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Conversation

@ddubrava
Copy link
Contributor

@ddubrava ddubrava commented Nov 5, 2020

fixes #2707

…eclaration within TSModuleDeclaration (#2707)
@typescript-eslint
Copy link

@typescript-eslint typescript-eslint bot commented Nov 5, 2020

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 bradzacher added the bug label Nov 6, 2020
':not(TSModuleDeclaration > TSModuleBlock) > TSInterfaceDeclaration'(
node: TSESTree.TSInterfaceDeclaration,
): void {
Comment on lines 71 to 73

This comment has been minimized.

@bradzacher

bradzacher Nov 8, 2020
Member

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

This comment has been minimized.

@ddubrava

ddubrava Nov 8, 2020
Author Contributor

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

This comment has been minimized.

@bradzacher

bradzacher Nov 8, 2020
Member

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
@ddubrava ddubrava changed the title fix(eslint-plugin): [consistent-type-definitions] ignore TSInterfaceDeclaration within TSModuleDeclaration (#2707) fix(eslint-plugin): [consistent-type-definitions] remove fixer when the interface is within a global module declaration (#2707) Nov 8, 2020
@ddubrava ddubrava requested a review from bradzacher Nov 8, 2020
@codecov
Copy link

@codecov codecov bot commented Nov 8, 2020

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
Copy link
Contributor Author

@ddubrava ddubrava commented Nov 8, 2020

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

ddubrava added 2 commits Nov 8, 2020
…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
Comment on lines 39 to 42

This comment has been minimized.

@bradzacher

bradzacher Nov 9, 2020
Member

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
@ddubrava ddubrava requested a review from bradzacher Nov 11, 2020
@bradzacher bradzacher changed the title fix(eslint-plugin): [consistent-type-definitions] remove fixer when the interface is within a global module declaration (#2707) fix(eslint-plugin): [consistent-type-definitions] remove fixer when the interface is within a global module declaration Nov 14, 2020
Copy link
Member

@bradzacher bradzacher left a comment

LGTM - thanks for this!

@bradzacher bradzacher merged commit 2326238 into typescript-eslint:master Nov 14, 2020
10 checks passed
10 checks passed
Typecheck
Details
Unit tests Unit tests
Details
Code style and lint
Details
Run integration tests on primary Node.js version
Details
Run unit tests on other Node.js versions (10.x)
Details
Run unit tests on other Node.js versions (14.x)
Details
Publish the latest code as a canary version
Details
Semantic Pull Request ready to be squashed
Details
codecov/patch 92.85% of diff hit (target 90.00%)
Details
codecov/project 92.80% (+0.00%) compared to e82698c
Details
@ddubrava ddubrava deleted the ddubrava:consistent-type-definitions-exclude-TSModuleDeclaration branch Nov 15, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

2 participants