-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
feat(51086): satisfies support in JSDoc #51753
Conversation
@typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the abridged perf test suite on this PR at 59b288f. You can monitor the build here. Update: The results are in! |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 59b288f. You can monitor the build here. |
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
@DanielRosenwasser Here they are:Comparison Report - main..51753
System
Hosts
Scenarios
Developer Information: |
@typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 7d823ae. You can monitor the build here. |
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
@DanielRosenwasser Could you take a look at these changes? I want to be sure about
|
I think the specific use case we had in mind was a /** @satisfies {{ f: (x: string) => string }} */
let obj1 = { f: s => s.toLowerCase() }; // should work
/** @satisfies {{ f: (x: string) => string }} */
let obj2 = { g: "oops" }; // should error similar to how an |
@DanielRosenwasser Here they are:
CompilerComparison Report - main..51753
System
Hosts
Scenarios
TSServerComparison Report - main..51753
System
Hosts
Scenarios
StartupComparison Report - main..51753
System
Hosts
Scenarios
Developer Information: |
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'm not sure it's necessary to fix the ParenthesizedExpression bug -- it's still an existing bug with @type
afaik -- but we should have tests for it.
660fa79
to
e19d791
Compare
…ializer expression. rename utilities.
e19d791
to
62b9c22
Compare
@typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 98f7db6. You can monitor the build here. |
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
So we tried
Those are the two things I would want to get fixed with this PR. Something minor that we noticed was that there are mismatches between what TypeScript does in annotation/assertion/satisfies positions, along with what the corresponding JSDoc equivalents are. // TS file
let a: string = 123;
// ~
let b = 123 as string;
// ~~~~~~~~~~~~~
let c = 123 satisfies string;
// ~~~~~~ // JS file
/** @satisfies {string} */
let a = 123;
// ~
let b = /** @type {string} */ (123);
// ~~~~~~
/** @satisfies {string} */
// ~~~~~~
let c = 123;
let d = /** @satisfies {string} */ (123);
// ~~~~~~ These are not consistent, but to be honest, I don't want you to change what you have in this PR because it would end up dragging it on and it's a separate concern from the feature itself. I'd rather file a separate follow-up issue instead. |
Fixes #51086