-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Better best effort type alias preservation #40232
Conversation
…to ensure locally accessible type aliases are materialized at printback time
@typescript-bot perf test this (this almost certainly has a cost) @typescript-bot pack this |
Heya @weswigham, I've started to run the tarball bundle task on this PR at 7d9bb77. You can monitor the build here. |
Heya @weswigham, I've started to run the perf test suite on this PR at 7d9bb77. You can monitor the build here. Update: The results are in! |
Heya @weswigham, I've started to run the parallelized community code test suite on this PR at 7d9bb77. You can monitor the build here. |
Heya @weswigham, I've started to run the parallelized Definitely Typed test suite on this PR at 7d9bb77. You can monitor the build here. |
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
@weswigham Here they are:Comparison Report - master..40232
System
Hosts
Scenarios
|
Does this PR address the non-propogation of type aliases described in point one in #45954, which makes proposals to Improve type readability? |
Unfortunately, we never finished reviewing this PR. It is pretty old now, so I'm going to close it to reduce the number of open PRs. |
In this PR, we record all[1] aliases we create for a type, rather than just the one we encounter on the adjacent declaration the first time we create a type, and then use that recorded list of aliases to improve declaration emit/printback in a more deterministic way.
Fixes #40092 and probably a lot of other stuff. I've labeled this as a potentially
Breaking Change
as the use of more aliases could affect people's declaration emit of inferred types - for example, thelib
PropertyKey
type is often used in place ofstring | number | symbol
(since it's a global type alias).[1]some aliases we could make, but likely just increase complexity, are intentionally omitted - this way we don't do things like printback
NonNullable<NonNullable<T>>
as a preferred "alias" ofT
.