[Bug]: 8.0.alpha default reactDocgen generates different output than in 7.x

[csantos1113]

Describe the bug

react-docgen generates different (and incomplete) documentation than react-docgen-typescript; and once #24165 lands the default documentation generated by Storybook will be significantly "bad" for typescript users using typescript path aliases and enums.

EDIT (@valentinpalkovic):

• Storybook has added TypeScript Path Aliases support when used with react-docgen

Originally posted by @csantos1113 in #24165 (comment)

To Reproduce

1. Go to https://stackblitz.com/edit/github-aca5uv-867pnb (EDIT: Path aliases are now supported)

• Notes:
  • this rep example uses typescript path aliases which are pretty common.
  • it also uses vite-tsconfig-paths for those paths to resolve in vite
  • it uses react-docgen (which will be the default in 8.0 once React: Set react-docgen to default TS docgen #24165 is merged)
• ⚠️ Notice:
  • The documentation is "unknown"
  • "controls" are broken
  • props documentation is gone
  • required props are gone

2. Go to https://stackblitz.com/edit/github-aca5uv-867pnb

• Notes:
  • this rep example does not use typescript path aliases. It's just relative imports
  • it uses react-docgen (which will be the default in 8.0 once React: Set react-docgen to default TS docgen #24165 is merged)
• ⚠️ Notice:
  • The documentation show up
  • required props show up
  • "controls" are still broken for enum values

3. Go to https://stackblitz.com/edit/github-aca5uv-xws82c

• Notes:
  • this reg example is the same as number 1 with path aliases and vite-tsconfig-paths
  • but it uses react-docgen-typescript instead
• 😍 Notice:
  • The documentation show up
  • required props show up
  • "controls" work fine for all types even enum values

System

`^8.0.0-alpha.0`, but also happening in `v7.x`.

Additional context

I understand there are foundational differences between the two libraries, and react-docgen has a bunch of open TypeScript related issues: https://github.com/reactjs/react-docgen/issues?q=is%3Aissue+is%3Aopen+typescript and the decision behind Storybook swapping the default docsgen library, and that keeping these 2 libraries working "the same" is not responsibility of the Storybook team ❤️

This is not really an issue with storybook per se, but the Storybook team might help push this forward in the right direction 🙏

I'm opening this issue per @shilman request: #24165 (comment)

Related issues

Related issues at react-docgen

Beta Give feedback

1. TS Path aliases seem to break type output reactjs/react-docgen#456
   +0
2. Better TS enum support reactjs/react-docgen#877
   new feature +1

[shilman]

@valentinpalkovic it would be great if we could support tsconfig paths in the react-docgen resolver for both webpack & vite. WDYT?

[valentinpalkovic]

Relates to reactjs/react-docgen#456.

@shilman we could indeed try to provide a custom importer, which handles path aliases, or someone/we contribute directly to react-docgen.

[valentinpalkovic]

At least reactjs/react-docgen#456 was fixed in Storybook by adjusting react-docgen's default resolver.

It will be part of the next 8.0.0-rc.2 prerelease!

[macrozone]

react-docgen also does not seem to work in my setup:

• i have a monorepo setup, with "ui" (where storybook lives) and a "theme" package
• the "theme" package only contains components from gluestack, its basically just a package containing the ejected gluestack library
• the "ui" package declares its own components which are composed from "theme"-components, for example a Button

"use client";
import {
  Button as ButtonBase,
  ButtonText,
  ButtonIcon,
  ButtonSpinner,
} from "theme";
import type { ComponentProps } from "react";

export type ButtonProps = { title: string } & Pick<
  ComponentProps<typeof ButtonBase>,
  "onPress" | "variant" | "action" | "size"
> & {
    Icon?: ComponentProps<typeof ButtonIcon>["as"];
    processing?: boolean;
  };
export const Button = ({ title, Icon, processing, ...rest }: ButtonProps) => {
  return (
    <ButtonBase {...rest}>
      <ButtonText>{title}</ButtonText>

      {Icon ? <ButtonIcon as={Icon} /> : null}
      {processing ? <ButtonSpinner /> : null}
    </ButtonBase>
  );
};

• the story:

import type { Meta, StoryObj } from "@storybook/react";

import { Button } from "./Button";

export default {
  title: "primitives/Button",
  component: Button,

  parameters: {
 layout
    layout: "centered",
  },

docs/autodocs
  tags: ["autodocs"],
 };

type Story = StoryObj<typeof Button>;

export const Default: Story = {
  args: {
    title: "Button",
  },
};

• when i use "react-docgen", i only see the explicitly set props from the typescript types:

• when i use "react-docgen-typescript" i see all props:

---

i am unsure whether it is a problem similar to reactjs/react-docgen#456 or something else

[itsezc]

Facing the exact same issue as @macrozone, with React 18 and Vite, if I'm not mistaken react-docgen-typescript is the Webpack plugin being used?

[jtiala]

The problem also occurs with tuple types generated from string arrays with const assertion, i.e.

const pets = ['cat', 'dog'] as const;
type PetTuple = typeof pets;
type Pet = PetTuple[number];

This way of defining types is very useful as you can define the values only once as both type and values.

Repro here: https://stackblitz.com/edit/github-y9fajh?file=src%2Fstories%2FExample.tsx

Only string literal unions work as expected with react-docgen while tuples and enums work fine with react-docgen-typescript.

I'm using 8.5.0-alpha.3