Open nickpelone opened 4 years ago
nickpelone
commented
4 years ago Nano-update on my workaround:
It also appears that the type tag parser is interpreting my type as a String? Or maybe I'm just reading this wrong?
(notice in the hovertext the Error type is stringified, "Error")
Sorry for additional noise.
runem
commented
4 years ago Hi Nick, thanks for creating this issue and making me aware of it!
First of all, lit-plugin right now runs with a very old version of web-component-analyzer. Testing what you showed with the newest version doesn't crash for me (so your first issue seems to have been fixed with the next version):
npx web-component-analyzer analyze my-element.jsNext, the reason it doesn't see complex types such as "Error" is because of a missing feature in ts-simple-type. You can read more about it in this issue: https://github.com/runem/ts-simple-type/issues/32 . It's definitely on my list of high priority bugs, so I'll come by it soon! I'll keep you updated here, and sorry for the inconvenience :-)
nickpelone
commented
4 years ago Hey, thanks for the update! Much appreciated :smile:
runem
commented
4 years ago Update: Support for nullable JSDoc type is now live in version 1.1.6 of the vscode plugin.
You can add "lit-plugin.rules.no-incompatible-type-binding": "off" to your vscode settings to disable type checking while waiting for a fix to the above mentioned problem with the "Error" type in JSDoc.
The following would also fix your issue (if you want to use public class fields):
class ErrorDialog extends LitElement {
/**
* @type {Error}
*/
error;
}I have also taken the freedom to rename this issue :-)
nickpelone
commented
4 years ago Sweet! After updating, things no longer crash with an @prop {?Error} annotation. As you said, the typcheck on the binding still shows as incorrect, but I can patiently await that fix. :)
Thanks again! I'm going to be on-boarding some of my team to modern web practice stuff and your plugin is just a really nice quality of life enhancement.
This is an intersection with the VSCode plugin, but from my logs this is the underlying component that has the issue.
First of all, thank you very much for your plugin, it's awesome!
I just noticed that a nullable type in a
@propJSDoc tag seems to crash language server features. For example, after typing the below example@propline, other custom elements in my template no longer get hover-info, autocomplete etc.Example:
The
@prop {?Error} errorbit seems to mess it up. Just for sureness' sake, I tried nullable notation on other types, eg.Numberand the same result occurred.The logs I get when I enable verbose logging in the VSCode plugin:
Looking at that call stack, the second section looks like this:
which led me to infer that it might be the nullable notation, given the regex used there.
If I change the
@propline to:@prop {Error | null}(ultimately, the same thing), everything works again.This is obviously not a showstopper, as like I mentioned you can just use the union type notation instead and work around it in the meantime.
Just wanted to let you know - thanks for your time!