JSDoc with Composition API doesn't work with PropType format on hover

[cabal95]

When using the composition API and defineComponent(), Volar doesn't seem to pick up the comments when we use the PropType format (that might not be the right term, but example will be below showing what I mean).

We have a number of pure TS file components. These can't easily be changed to .vue files so we are kind of stuck with them. Some of them don't even have a template, so I'm not sure if those even could be converted to SFC files.

Anyway, we have props declared like this:

props: {
  /** JSDoc comment that does not get detected. */
  msg: {
    type: String as PropType<string>,
    default: "Some value here."
  }
}

When we use that component in a .vue SFC file and hover over the "msg" prop, it correctly picks up the type but not the comment.

If we use the simple format of just:

props: {
    /** JSDoc comment that does get detected. */
    msg: String
}

Below are two images that show what I am referring to. The comment for "inlineMsg" is detected, but the comment for "msg" is not.

So, questions:
A) Is there anything that can be changed in Volar to work with these?
B) Is there another syntax we can use (without going to SFC files for the components in question) that would make the comments be detected?

Bonus points: I tried cloning the volar repo to run inside VSCode so I could set breakpoints and try to figure out if this was something I could help with and provide a pull request, but I wasn't even able to get the repo to build. After running "pnpm i" and then running "npm run build" I get build errors about things like "ws" not having type definitions. Is there a doc or wiki page or something that describes how to get going in this way?

[johnsoncodehk]

This is defineComponent types behavior, the command message is drop by type gymnastics with default property. You could open a issue to vue repo.

// test.ts
import { defineComponent } from "vue";

const Foo = defineComponent({
    props: {
        /** This is the comment */
        msg: {
            type: String,
            default: '',
        },
        /** This is the comment without default */
        msgWithDefault: {
            type: String,
        },
        /** This is the inline comment */
        inlineMsg: String,
    }
});

const foo = new Foo();
foo.$props.msg; // no works
foo.$props.msgWithDefault; // works
foo.$props.inlineMsg; // works

A) Is there anything that can be changed in Volar to work with these?

Volar can't change this TS behavior, unless we force collect comment text by TS find definition additionally. But this way is hacky I want to avoid to do, resolve in type gymnastics is better.

B) Is there another syntax we can use (without going to SFC files for the components in question) that would make the comments be detected?

With <script setup>, you can use defineProps type only define. Sorry it can't avoid the default property type gymnastics problem.

<script setup lang="ts">
withDefaults(defineProps<{
  /** This is the comment */
  msg?: string,
  /** This is the inline comment */
  inlineMsg?: string,
}>(), {
  msg: '',
});
</script>

Bonus points: I tried cloning the volar repo to run inside VSCode so I could set breakpoints and try to figure out if this was something I could help with and provide a pull request, but I wasn't even able to get the repo to build. After running "pnpm i" and then running "npm run build" I get build errors about things like "ws" not having type definitions. Is there a doc or wiki page or something that describes how to get going in this way?

Please track #1055.

$ pnpm i && npm run build should not have error, what error message you have?

[cabal95]

This is defineComponent types behavior, the command message is drop by type gymnastics with default property.

Ahh, so it's just the fact we are using default. We can probably work around that and provide a default value via computed. Thank you for clarifying that point. It just so happened the only props I had tried this on were all ones that had a default vs any marked as required.

You could open a issue to vue repo.

I'll look into that too now that I know it's an issue there. I assumed Vue just didn't support the comments at all itself because even inside a setup(props) { ... } function, none of the JSDoc comments show up in for props.msg. It might work with <script setup>, but these existing files are currently all .ts files, so defineComponent is our only option at the moment.

$ pnpm i && npm run build should not have error, what error message you have?

$ git clone https://github.com/johnsoncodehk/volar
$ cd volar
$ pnpm i
$ npm run build


> @ build /home/daniel/volar
> tsc -b tsconfig.build.json

packages/shared/src/common.ts:2:30 - error TS2307: Cannot find module 'vscode-languageserver-types' or its corresponding type declarations.

2 import type * as vscode from 'vscode-languageserver-types';
                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

packages/shared/src/common.ts:55:31 - error TS2550: Property 'matchAll' does not exist on type 'string'. Do you need to change your target library? Try changing the 'lib' compiler option to 'es2020' or later.

55  for (const match of lineText.matchAll(wordPattern)) {
                                 ~~~~~~~~

packages/shared/src/http.ts:1:23 - error TS2307: Cannot find module 'http' or its corresponding type declarations.

1 import * as http from 'http';

There are more but you get the idea. :) If the steps I used are indeed correct (which sounds like they are), I'll test a few other host environment setups and then open a new issue with more details about environment.

[johnsoncodehk]

@cabal95 Build error fixed by de487c1, thanks to report it.

[johnsoncodehk]

JSDoc issue fix in vuejs/core#5871.

[cabal95]

@johnsoncodehk Thanks for going the extra kilometer to find, fix and submit the PR to the Vue team!

[johnsoncodehk]

Duplicate of #703

[lmiller1990]

If anyone else runs into this general issue, I had some luck like this:

Worth nothing that adding type: Array makes the type inference worse - using default in combination with @typedef` seems to be the best option (except using real TS, which may not be an option for some people).