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

Actually have a chance to reuse optional property signatures in the node builder #57995

Merged
merged 1 commit into from
Mar 29, 2024

Conversation

weswigham
Copy link
Member

As you can see, I'd forgotten PropertyDeclaration and PropertySignature were not caught by the same check when I originally wrote this comparison, so optional property signatures (that didn't have an explicit undefined written out) never got reused in the node builder. And PropertySignatures are the ones actually within type nodes!

@typescript-bot typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Mar 29, 2024
@jakebailey
Copy link
Member

I feel nervous about this one in the same way I felt nervous about other reuses when exactOptionalPropertyTypes gets involved. Makes me wonder if all of these sorts of things have accidentally made the flag easier to use...

@weswigham
Copy link
Member Author

Makes me wonder if all of these sorts of things have accidentally made the flag easier to use...

Hope not, since if you write a declaration at the top level, it's already appropriately kept in the fashion in which it was written. Here's a demonstration:

// @declaration: true
// @strict: true
export const a: { key?: { x?: number } } = {};
                 //^?


export const b = () => ([null as any as { key?: { x?: number } }][0]);
           //^?

Workbench Repro

Despite being declared in the exact same way, a lacks | undefined on its' optional properties in the declaration emit (because it was defined without them and we used those nodes), while b has | undefined in all its' optional types (and quickinfo for both has | undefined). The irony here is that when you set exactOptionalPropertyTypes, this is corrected, and the | undefined is removed from both because of the missing-type-removal calls inserted to handle it. (And yes, before you ask, the inline hint for the //^? has different text than the assertion result in the sidebar - I could not tell you why; maybe inline hints in the workbench get calculated without the compiler options set?)

We already respect user intent and keep their nodes as-is sometimes, all this does is make us do it more often - that probably makes this a (at least partial) bugfix, and not just an experience improvement 🤷‍♂️

@typescript-bot typescript-bot added the Has Repro This issue has compiler-backed repros: https://aka.ms/ts-repros label Mar 29, 2024
@jakebailey
Copy link
Member

Yeah, I guess for isolated declarations we weren't going to throw | undefined on everything randomly...

@weswigham weswigham merged commit b0042a7 into microsoft:main Mar 29, 2024
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug Has Repro This issue has compiler-backed repros: https://aka.ms/ts-repros
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants