-
Notifications
You must be signed in to change notification settings - Fork 1k
fix(analyzer): jsdoc type order, lowercase tags, css syntax #4132
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
fix(analyzer): jsdoc type order, lowercase tags, css syntax #4132
Conversation
🦋 Changeset detectedLatest commit: fc277af The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Tachometer Benchmark ResultsSummarynop-update
render
update
update-reflect
Resultsthis-change
render
update
update-reflect
this-change, tip-of-tree, previous-release
render
update
nop-update
this-change, tip-of-tree, previous-release
render
update
this-change, tip-of-tree, previous-release
render
update
update-reflect
|
WIP: typescript types only!
|
for this initial review, I took the approach of checking the first char of the event comment for a |
justinfagnani
left a comment
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.
This looks great! Amazing tests!
My only question is about the return type of the jsdoc parsing and why we can't use parseNamedTypedJSDocInfo for parsing CSS properties.
| default?: string; | ||
| } | ||
|
|
||
| export interface NamedDescribedSyntax extends NamedDescribed { |
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.
Is this a generic interface for anything with a syntax, or is a specific interface now for a CSS property? I think it might be nicer to read if this were just CSSPropertyInfo or something.
| case 'cssProp': | ||
| addNamedJSDocInfoToMap(cssProperties, tag, analyzer); | ||
| break; | ||
| case 'cssprop': |
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.
Do we really care about the cases like this, or can we lowercase the tag before hitting the switch statement to get a case-insensitive comparison?
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 initially lowercased the tag, but like ... @cSsPRop...
| return undefined; | ||
| } | ||
| const nameTypeDesc = comment.match(parseNameTypeDescRE); | ||
| const regex = comment.startsWith('{') |
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.
this seems fine to me!
This still requires a lookaround for the case of event with inline detail
justinfagnani
left a comment
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.
Loogs great!
|
Thanks a lot @bennypowers! I'll merge as soon as the tests pass. |
@cssproperty,@cssprop,@csspart(all lowercase)@fires {Type} event-name - description@cssProp {<syntax>} [--name=default] - description