-
Notifications
You must be signed in to change notification settings - Fork 15
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
Code fixer improvements. #96
Code fixer improvements. #96
Conversation
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
…d property as is if possible. Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
90c8e5c
to
57d243a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with some nit and questions. Thank you for the changes!
tests/cases/fourslash/codeFixMissingTypeAnnotationOnExports45-no-enum-members.ts
Outdated
Show resolved
Hide resolved
//// ] | ||
////} | ||
|
||
verify.codeFix({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two fixes here seems to be identical
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean. The two fixes work in tandem here. The first will extract the property value to a variable and then the second one annotates the variable.
// @declaration: true | ||
|
||
// @Filename: /person-code.ts | ||
////export type Person = { x: string; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if it's not exported? Is this worth a test case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll investigate. I think it might be a TS error (using a private name). But I don't think we test for it.
// @declaration: true | ||
// fileName: code.ts | ||
////export const extensions = { | ||
//// /** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Do we need this comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to make sure the JS doc comment is preserved in the same position. With the previous way of adding the annotation (using replaceNode), comments were duplicated. I want to make sure we do not regress this.
src/services/services.ts
Outdated
@@ -510,7 +510,9 @@ function addSyntheticNodes(nodes: Node[], pos: number, end: number, parent: Node | |||
if (hasTabstop(parent)) { | |||
continue; | |||
} | |||
Debug.fail(`Did not expect ${Debug.formatSyntaxKind(parent.kind)} to have an Identifier in its trivia`); | |||
// Not sure why this is here. When I try to make text change that contains only a property assigment this kicks in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you phrase this into a TODO?
@@ -6992,6 +6992,42 @@ | |||
"category": "Message", | |||
"code": 90060 | |||
}, | |||
"Add annotation of type '{0}'": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These look great :)
I cannot find the usages, will these be standalone separate diagnostics, or do these fall under a sub-diagnostic i.e. Diagnostic.relatedInformation
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are used as the fixer descriptions in src\services\codefixes\fixMissingTypeAnnotationOnExports.ts
.
external-declarations/src/code-mod/tsc-test-fixer/test-fixer.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question - do you intend to ship the interactive fixer in mainstream TS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not. A version of it will be in the tests probably, but I expect to reimplement it in a standalone project and open source that. But none of this has been set in stone, it's just my current thinking.
if (propertySymbol.declarations) { | ||
const decl = first(propertySymbol.declarations); | ||
const decl = propertySymbol.declarations && first(propertySymbol.declarations); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what this code(the changes) is doing, can you explain with an example code snippet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to be able to force the compiler to preserve the computed property expressions in types instead of resolving them, if the computed property is an accessible entity name (identifier, or identifier chain):
So for example for:
const A = 1;
const E = { A: 2 } as const
let o = { [A]: 1, [E.A]: 2 }
The checker would always produce as the type of o
: { [1]: number, [2]: number }
which is correct but not a type a dev would ever write. With this change, if A
and E.A
are accessible in the current scope (either are already in the scope or can be imported), they will be preserved and we get { [A]: number, [E.A]: number }
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
Signed-off-by: Titian Cernicova-Dragomir <tcernicovad1@bloomberg.net>
1cad6d7
to
430bedc
Compare
Code fixer improvements.