-
Notifications
You must be signed in to change notification settings - Fork 878
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
[labs/analyzer] Collect and log non-fatal diagnostics. #3678
Conversation
…`ts.DiagnosticCategory`.
🦋 Changeset detectedLatest commit: a0f3911 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
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
Resultslit-element-list
render
update
update-reflect
lit-html-kitchen-sink
render
update
nop-update
lit-html-repeat
render
update
lit-html-template-heavy
render
update
⏱ reactive-element-list
render
update
update-reflect
|
I thought it might be useful to collect diagnostics for each module individually and also have a single list with all diagnostics in a program, but there's nothing that needs this right now.
This mostly reverts commit 24ba127, but leaves the part that ignores function overloads.
…ith unsupported name types.
packages/labs/analyzer/test-files/ts/functions/src/functions.ts
Outdated
Show resolved
Hide resolved
packages/labs/analyzer/test-files/ts/properties/src/element-a.ts
Outdated
Show resolved
Hide resolved
// Fields named with symbols are visible in the `fields` iterator. | ||
const field = Array.from(element.fields).find( | ||
(x) => x.name === '[unsupportedPropertyName]' | ||
); | ||
assert.ok(field); |
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 think this behavior is really a bug. Symbol-named properties make it into fields
here:
lit/packages/labs/analyzer/src/lib/javascript/classes.ts
Lines 89 to 100 in be18292
} else if (ts.isPropertyDeclaration(node)) { | |
const info = getMemberInfo(node); | |
(info.static ? staticFieldMap : fieldMap).set( | |
node.name.getText(), | |
new ClassField({ | |
...info, | |
default: node.initializer?.getText(), | |
type: getTypeForNode(node, analyzer), | |
...parseNodeJSDocInfo(node), | |
}) | |
); | |
} |
...which doesn't seem to care what type of name a property is using, but I'm not sure if that was intentional or not. node.name
is the AST node for however the name of a field is described, so its getText()
ends up returning the name with brackets around it, which looks reasonable but is really just JS text. (I think getText()
would return ["abc" + "def"]
for a field like class { ["abc" + "def"] = 123; }
.)
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.
hmm...is that a bug? What do we want the name to be? I could see that for the text representation, that something like [mySymbol]
is about as good as we can get. But to fully support Symbol-named fields we probably want to represent them as a reference in the manifest, so we'd need to keep the name AST node.
I think that symbol-named fields are rare enough that we could punt on a few things, keep issues, then come back with a push to support symbols better, including adding name reference support to ClassField and ClassMethod: https://github.com/webcomponents/custom-elements-manifest/blob/main/schema.d.ts#L557
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.
Justin what you said makes sense if name
were only used as the display name in the model (probably the best we can do), but it's also used as the key in the map for getField(name)
, and you wouldn't look up a class model's symbol-based field using a string like getField('[mySymbol]')
-- you'd probably need to construct and pass a reference.
Let's add a TODO (there's already an issue for dealing with Symbol-based fields), and I think it'd be fine to log an error/warning here if the name is not an identifier, at least for now.
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've updated this to also log a diagnostic rather than analyzing the property.
…nilla JS classes.
This reverts commit 1a98ee7.
@@ -73,6 +75,18 @@ export class Analyzer implements AnalyzerInterface { | |||
), | |||
}); | |||
} | |||
|
|||
addDiagnostic(options: DiagnosticOptions) { |
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.
Originally I had this parameter as a Diagnostic
but then I changed it to DiagnosticOptions
since it made the user-side of this API a bit cleaner but I'm still on the fence about it. WDYT?
*getDiagnostics(): IterableIterator<ts.Diagnostic> { | ||
yield* this.diagnostics; | ||
} |
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 feels like something that someone using the analyzer's API would want but it's only used in tests as of now. Should I update this to avoid putting on the public API for now?
Superceded by #3866 |
This adds a few methods to the analyzer for collecting and logging diagnostics. The analyzer no longer crashes when it sees a
LitElement
extension that has a non-identifier property name and instead adds a warning diagnostic. Also, the CEM generator now logs any diagnostics that were added after it generates the manifest.