-
Notifications
You must be signed in to change notification settings - Fork 21
fix: resolve property assignments in object literals #373
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
Conversation
Arrays of objects create definitions for all object keys contained
This follows the implementation I found in the TypeScript goToDefinition service https://github.com/microsoft/TypeScript/blob/88809467e8761e71483e2f4948ef411d8e447188/src/services/goToDefinition.ts#L307-L316
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 reviewed the LSP implementation quite thoroughly and did not find getContextualType
. It makes a ton of sense that this API exists, and I'm 100% in favor of this much simpler approach. I would try porting some of the tests from the other PR to see how it behaves.
This change is a significantly quality improvement for TypeScript navigation so I think it's absolutely worth it to get this through the finish line.
without these `npm run eslint` wouldn't pass locally
c909a93
to
9c755a7
Compare
9c755a7
to
a7ad7bd
Compare
8dc6cca
to
bd71c9d
Compare
bd71c9d
to
d235021
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.
This is glorious. Ship it!
@@ -49,7 +49,7 @@ export const LoaderInput2: React.FunctionComponent<Props> = props => { | |||
return <LoaderInput loading={true} key="key" children={props.children} /> | |||
// ^^^^^^^^^^^ reference react-example 1.0.0 src/`LoaderInput.tsx`/LoaderInput. | |||
// ^^^^^^^ reference react-example 1.0.0 src/`LoaderInput.tsx`/Props#loading. | |||
// ^^^ reference local 10 | |||
// ^^^ reference @types/react 18.2.39 `index.d.ts`/React/Attributes#key. |
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.
😍
|
||
@MyDecorator({ property: 42, property2: '42' }) | ||
//^^^^^^^^^^^ reference syntax 1.0.0 src/`decorators.ts`/MyDecorator(). | ||
// ^^^^^^^^ reference syntax 1.0.0 src/`reusable-types.ts`/Numbers#property. |
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.
👏🏻
// ^^^^^^ reference syntax 1.0.0 src/`object-literals-arrow-function.ts`/Foobar# | ||
return fn({ foobar: 42 + something }) | ||
// ^^ reference syntax 1.0.0 src/`object-literals-arrow-function.ts`/hasArrowFunctionParameter().(fn) | ||
// ^^^^^^ reference syntax 1.0.0 src/`object-literals-arrow-function.ts`/Foobar#foobar. |
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.
Woo hoo, this is such a significant leap for navigation quality. Closest huge gap against tsserver
if (!objectElement) { | ||
return | ||
} | ||
const contextualType = this.checker.getContextualType(objectElement.parent) |
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.
So much heavy lifting here.
// even if `this.checker.getTypeAtLocation({y: 42})` does not return | ||
// `SomeInterface`. The object literal could satisfy many types, but in this | ||
// particular location must only satisfy `SomeInterface`. | ||
private inferredTypeOfObjectLiteral( |
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.
❤️❤️
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.
Yeah this one felt pretty good :D
Simpler alternative to #256
This follows the implementation I found in the TypeScript goToDefinition service https://github.com/microsoft/TypeScript/blob/88809467e8761e71483e2f4948ef411d8e447188/src/services/goToDefinition.ts#L307-L316
Leans on the TypeScript compilers
getContextualType
function to resolve object literals to the interfaces, or type definitions they are being checked against. This means we generate useful references in a lot more places, where we'd generate "dead" definitions before.Test plan
Ports all tests from #256 and adds some basic new ones. Check the updated snapshot output to gauge the improvement or if there are any regressions.