JSDoc string literal types #9995
Conversation
Unfortunately, I didn't find a way to reuse the normal string literal type, so I had to extend the existing JSDoc type hierarchy. Otherwise, this feature is very simple.
| @@ -346,6 +346,7 @@ namespace ts { | |||
| JSDocTypedefTag, | |||
| JSDocPropertyTag, | |||
| JSDocTypeLiteral, | |||
| JSDocStringLiteralType, | |||
|
|
|||
There was a problem hiding this comment.
You may need to update the LastJSDocNode and LastJSDocTagNode pointers
|
@DanielRosenwasser do you mind taking a look since you did the rest of string literal types? |
| * @param {'literal' | number} p4 | ||
| */ | ||
| function f(p1, p2, p3, p4) { | ||
| return p1 + p2 + p3 + p4 + '.'; |
There was a problem hiding this comment.
Does this test really do anything apart from test baselines? Why not write some tests that have observable characteristics from a usage standpoint?
For instance, string completion when calling something that takes a union type of string literals.
There was a problem hiding this comment.
Good idea to add a string-literal-specific test. I didn't even know that we offered completions in strings.
This test checks that the jsdoc parser gets the types right. It's in a JavaScript file so the parameter types would otherwise be any. That will produce a lot of observable differences in parameter help and quick info. But I trust those work if the checker can get the types right.
There was a problem hiding this comment.
Done.
Hilariously, @Filename is case-sensitive in fourslash tests, but not compiler and conformance tests.
Also, Codeflow has two Give Feedback buttons, and they are not the same -- one is the inverse colour of the other.
OK, I'm done complaining now.
|
All right, now that I merged with master, JSDoc supports all literal types. |
| case SyntaxKind.StringLiteral: | ||
| case SyntaxKind.NumericLiteral: | ||
| case SyntaxKind.TrueKeyword: | ||
| case SyntaxKind.FalseKeyword: |
There was a problem hiding this comment.
need NeverKeyword and UndefinedKeyword here too
There was a problem hiding this comment.
Actually, those are not literal types, it turns out. In the interests of getting this PR in, I'll do those separately.
There was a problem hiding this comment.
They probably need their own special handling (see the lines preceding the diff in checker)
|
Can you update the switch statement for parsing, otherwise 👍 |
Fixes #9902
Unfortunately, I didn't find a way to reuse the normal string literal type, so I had to extend the existing JSDoc type hierarchy. Otherwise, this feature is very simple.