Quick fix to correct qualified names to indexed access types - #17462
Conversation
Arthur Ozga (aozgaa)
left a comment
There was a problem hiding this comment.
Not sure you want to make changes to get the fix working in the case mentioned below, but please add a test.
| const token = getTokenAtPosition(sourceFile, context.span.start, /*includeJsDocComment*/ false); | ||
| const qualifiedName = getAncestor(token, SyntaxKind.QualifiedName) as QualifiedName; | ||
| Debug.assert(!!qualifiedName, "Expected position to be owned by a qualified name."); | ||
| if (!isIdentifier(qualifiedName.left)) { |
There was a problem hiding this comment.
This example doesn't seem to trigger the right error, though we can apply the fix manually to fix the issue:
module M {
export interface I {
foo: string;
}
}
let a: M.I.foo;
Please add a test.
| @@ -1,3 +1,4 @@ | |||
| /// <reference path="correctQualifiedNameToIndexedAccessType.ts" /> | |||
| /// <reference path="fixClassIncorrectlyImplementsInterface.ts" /> | |||
There was a problem hiding this comment.
Looks like there is an analogous entry to this in src/harness/tsconfig.json. Not sure why it's there, or if we might want to remove it. Or alternatively, add a reference to correctQualifiedNameToIndexedAccessType.ts.
Wesley Wigham (@weswigham) do you know if building for tests will correctly trigger a rebuild when we make changes to correctQualifiedNameToIndexedAccessType.ts?
|
Arthur Ozga (@aozgaa) no, I didn't generalize the check, but I can at a later point. I did add a negative fourslash test, and augmented the tests added in #17459. |
…e already referenced in 'src/harness/codefixes/fixes.ts'.
Fixes #17461