v2.0.0 - Regression in parsing @default

[bebraw]

While trying to upgrade react-docgen-typescript-plugin to use v2.0.0 in order to get the .trim() fix in, I discovered a small regression related to parsing @default.

I've set up two repositories for you to check:

• https://github.com/bebraw/react-docgen-typescript-plugin/tree/fix-trim-is-not-a-function - Upgrade to v2. It's best to use yarn test
• https://github.com/styleguidist/react-docgen-typescript/tree/fix-missing-default - I ported the problematic test case here to verify it's failing at parser. I'm not sure that the test is 100% correct but it seems to confirm the behavior.

Here are some screenshots I took during the investigations:

[shilman]

Thanks @bebraw! Would love to get this into Storybook 6.3 if there's a fix in soon.

[CosticaPuntaru]

I have a similar issue with @type,
also i was using a custom prop @ignore and propFilter to remove props using it, now the description dose not have any @ related content

[ecraig12345]

This is due to using react-docgen-typescript >= 2 with typescript versions < 4.3 (looks like 3.8 in the react-docgen-typescript-plugin repro branch).

TS 4.3 changes the type of ts.JSDocTagInfo.text from string to ts.SymbolDisplayPart[], which was the cause of the (tag.text || '').trim() is not a function error others reported. #360 fixed that issue by parsing tag text using ts.displayPartsToString, but this broke compatibility with earlier TS versions (and the typescript peer dep has been updated accordingly--so on an earlier TS version, you must use react-docgen-typescript 1.x).

The unfortunate thing is that the changes needed to support both older and newer TS versions are pretty minimal, as shown in this branch commit (the rest of the change is for testing)--so supporting 4.3 didn't actually need to be a breaking change. It's especially unfortunate because this means that if anything using this library (such as storybook) wants to support 4.3, they must also require consumers to upgrade to 4.3, which may not be feasible right away.

I'd be happy to submit a PR from this branch to restore support for older TS if it's not too odd to revert the constraint that prompted a major release. Right now the branch has tests confirming support back to 3.0 but I could change it to not go back quite that far if desired. (My team's project is currently on 4.1.)

[github-actions]

There was no activity for a long time. The issue will be closed soon.

[github-actions]

Closing this issue as obsolete.