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.

Sign up for GitHub

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

Jump to bottom

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

Merged
merged 5 commits into from Nov 14, 2020
Merged

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

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
cbcc618
fix(eslint-plugin): [consistent-type-definitions] ignore TSInterfaceD…
Nov 5, 2020
867868b
fix(eslint-plugin): [consistent-type-definitions] remove fixer when t…
Nov 8, 2020
6d10e05
refactor(eslint-plugun): [consistent-type-definitions] mention the is…
Nov 8, 2020
945b193
test(eslint-plugin): [consistent-type-definitions] add cases when TSM…
Nov 8, 2020
4d14d68
refactor(eslint-plugin): [consistent-type-definitions] replace lookin…
Nov 10, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 3 additions & 1 deletion packages/eslint-plugin/src/rules/consistent-type-definitions.ts
View file
Open in desktop
Expand Up @@ -68,7 +68,9 @@ export default util.createRule({
});
}
},
TSInterfaceDeclaration(node): void {
':not(TSModuleDeclaration > TSModuleBlock) > TSInterfaceDeclaration'(
node: TSESTree.TSInterfaceDeclaration,
): void {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@ddubrava ddubrava Nov 8, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

if (option === 'type') {
context.report({
node: node.id,
Expand Down
10 changes: 10 additions & 0 deletions packages/eslint-plugin/tests/rules/consistent-type-definitions.test.ts
View file
Open in desktop
Expand Up @@ -59,6 +59,16 @@ export type W<T> = {
`,
options: ['type'],
},
{
code: `
declare global {
interface Array<T> {
foo(x: (x: number) => T): T[];
}
}
`,
options: ['type'],
},
],
invalid: [
{
Expand Down