Add basic jsdoc tag types #610
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I chose to create a wrapper type node for synthetic JS types rather than cloning the type node. This is how many other tags are going to work, like `@typedef` and `@overload`, so I think it makes sense. However, running tests points out that `@type` assertions, `@satisfies`, and the modifier-like tags like `@private` and `@readonly` will need to emit non-wrapped synthetic nodes, much like in microsoft#412. Much more work to be done here on replicating the host<->tag matching rules from Strada.
For example, recursive uses aren't done yet. Test diffs look generally right but are hard to evaluate without typedef and template tags, specifically.
Written mostly by AI, without reference to the original source. So it's going to need some cleanup.
It builds! But panics on tests!
sandersn
commented
Mar 14, 2025
| @@ -3032,6 +3046,7 @@ type ClassLikeBase struct { | |||
| DeclarationBase | |||
| ExportableBase | |||
| ModifiersBase | |||
| LocalsContainerBase | |||
There was a problem hiding this comment.
Unlike type, @typedef is allowed as a local inside classes.
I haven't checked to see how common this is so I added support for now as a way of fixing a nil panic. But I will remove it if it's not common.
sandersn
commented
Mar 14, 2025
| @@ -3268,6 +3283,55 @@ func IsTypeAliasDeclaration(node *Node) bool { | |||
| return node.Kind == KindTypeAliasDeclaration | |||
| } | |||
|
|
|||
| func IsEitherTypeAliasDeclaration(node *Node) bool { | |||
There was a problem hiding this comment.
I need to improve this name, maybe by asking Copilot for a name that sounds a little like a Pokemon.
- Transform `@typedef`+`@property` in a type object literal. - type check JSDoc types - add `@param` optionality when bracketed.
- refactor `@template` parsing to share constraints in multi-parameter tags - type `@template` tags - type assertions on parenthesised expressions - miscellaneous fixes - I looked at the diffs for compiler/ tests and skimmed the conformance/ ones. There are still some failures I want to fix.
nameresolver still needs to check for JS nodes because it will often start a walk upward looking at the *original* type nodes deeply nested in JSDoc. When it hits the JSDocTypeExpression, it should move over to the type expression's hosted position in the tree, such as a real parameter. The JS code is much less intrusive than before though.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Just a draft right now.
@type,@paramand@returnattach their types to their host's type annotations. These are not marked as synthetic yet, pending #521 to make the decision how to do so.@typedefemits a new JS type alias statement just before the jsdoc's host. In contrast to the other tags, the JS type alias has a separate kind and needs to be handled alongside normal type aliases. This isn't very valuable for type aliases, but will be more valuable for, say, CommonJS imports and exports, which have semantics that are different from TS' CommonJS import/export statements.TODO (among many other things):