TypeError: (tag.text || "").trim is not a function

[damiangreen]

We're getting this on node_modules/react-docgen-typescript/src/parser.ts:750:44
When running yarn run build-storybook
with the latest typescript ^4.4.0-dev.20210521, also doesnt work with 4.3

[alexeagleson]

Getting the same error on typescript 4.3.1-rc

[adharris]

This seems to be related to using @ tags in the doc comment. Removing them, while undesirable, appears to make this error go away.

[erik-beus]

This seems to be related to using @ tags in the doc comment. Removing them, while undesirable, appears to make this error go away.

We don't use any @ tags in our doc comments, but we still get the error 🤷

[adharris]

For me, it the vast majority comes from when i extend built in html props:

interface Props extends HTMLProps<HTMLDivElement> {
   /...
}

Those built in ones have @see directives all over the place

[nickbouton]

Having the exact same error with anything we export as Meta since upgrading to TypeScript 4.3.2.

This is the relevant line: https://github.com/styleguidist/react-docgen-typescript/blob/master/src/parser.ts#L750

Temporary workaround for now was just to disable reactDocgen entirely:

  typescript: {
    reactDocgen: 'none',
  },

[nickbouton]

FYI, did a little further digging here and it seems to be something (jsdoc seems likely) in our Material UI components that's triggering the issue. We're using Material UI core @ 4.11.4 and even importing + referencing something as simple as a Link alone is enough to set it off.

e.g. a quick replace of our Link component gets this story to pass:

e.g. this actually fails (notice additional LinkProps type import):

[michelengelen]

we had the same issue in our storybook project and I could (temporarily) solve it by resetting typescript to 4.2.2.
I will have a look at this issue though, so stay tuned! :D

[michelengelen]

Ok, I had a quick look into the problem. TScompiler now returns a different (and IMO improved value) from getJsDocTags. The now split the description/text into the correct use-cases (paramName, space and description).

The problem is, that there are several other changes introduced and right now this package is built upon using a locked TS version of 3.5.2. That means several other problems occur when bumping the version to a more recent (4.3.2) and I do not know if that is an expected change from @pvasek ?

If it is OK i would like to take up this task and bump the version and fix all errors that might occur with it, fixing this issue along the line.

I would also suggest to improve the tagMap on the JSDoc type to be a real map of sorts with a new structure (this would mean a major change though).

The new structure could look something like this:

tagMap: {
    type: string;    // <-- can be one of the `@` types from JSDoc (`@returns`, `@param`, etc)
    name?: string;    // <-- the parameter name
    description?: string;    // <-- the parameter description
}

[DustinBrett]

I noticed this same issue and edited the node_module so I could take a look at tag and what text is. It seems to now be an array of elements. The tag I got my failure on was:

{
  name: 'see',
  text: [
    { text: 'https', kind: 'text' },
    {
      text: '://html.spec.whatwg.org/multipage/interaction.html#input-modalities:-the-inputmode-attribute',
      kind: 'text'
    }
  ]
}

Which I may have tracked down to this JSDoc tag. https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L1869.

I am wondering if this @see tag had been in a different format such as the one mentioned here https://jsdoc.app/tags-see.html (* @see {@link ...}). Maybe it would have worked and returned a string to tag.text or possibly in TypeScript 4.3 it will always return an array of these { text, kind } (SymbolDisplayPart) objects.

I see on this line (https://github.com/styleguidist/react-docgen-typescript/blob/master/src/parser.ts#L744) that react-docgen-typescript is making use of getJsDocTags which I think may be involved in this.

I did some digging into the TS 4.3 update and I wonder if this change (https://devblogs.microsoft.com/typescript/announcing-typescript-4-3/#jsdoc-link-tags) could be involved. The PR (https://github.com/microsoft/TypeScript/pull/41877/files#diff-c989327fa8e0b2f600be4a19bc5b6f2cc2e9d157e8b2b85917645ecfa4df4652R157) for that change mentions changing the way @see tags are parsed.

Anyway that is my initial looking around, hopefully helps someone. In our case we have just reverted from TS 4.3 in the interim.

[michelengelen]

That definitely helps to understand the reasoning behind the change ... I already found out about the new structure as mentioned above.

I am currently looking into solving this. Stay tuned!

[farukbigez]

not a fix but downgrading typescript to 4.2.2 covers up the issue but not fixing it. for lazy programmers: yarn add --dev typescript@4.2.2