Automatic argTypes if component TypeScript prop types are imported

[martynhoyer]

Summary

Hi!

I've got some components which import their types from a shared types file because the same types are used throughout the codebase in different components. Here's a reduced example of a component with a status prop, which is limited to three potential options; "inProgress" | "completed" | "deleted"

You can see in HeaderCardProps, the status prop's value is imported from a shared file.

import * as React from "react";
import type { Status } from "../shared/interfaces";

interface HeaderCardProps {
    status: Status;
}

export function HeaderCard({
    status,
}: HeaderCardProps) {

    function renderStatusBadge(status: HeaderCardProps["status"]) {
        switch (status) {
            case "inProgress":
                return (
                    <StatusBadge status="neutral" variant="secondary">
                        In progress
                    </StatusBadge>
                );
            case "deleted":
                return (
                    <StatusBadge status="negative" variant="secondary">
                        Deleted
                    </StatusBadge>
                );
            case "completed":
                return (
                    <StatusBadge status="positive" variant="secondary">
                        Completed
                    </StatusBadge>
                );
        }
    }

    return (
        <Card>
            <Card.Header actionBar={renderStatusBadge(status)} />
        </Card>
    );
}

When I create a Storybook story for that component and use Autodocs, I'd expect the props table to give me those three options as a <select> or radio buttons, but instead, it gives me a string. This is what my story code looks like:

import type { Meta, StoryObj } from "@storybook/react-webpack5";
import { HeaderCard } from "./HeaderCard";

const meta = {
    component: HeaderCard,
    tags: ["autodocs"],
} satisfies Meta<typeof HeaderCard>;

export default meta;

type Story = StoryObj<typeof HeaderCard>;

export const MandatoryPropsOnly: Story = {
    args: {
        status: "inProgress",
    },
};

And here's a screenshot of the props table in Storybook for that story:

If I remove the imported type and hard code the values instead, like this

interface HeaderCardProps {
-    status: Status;
+    status: "inProgress" | "deleted" | "completed";
}

Then Storybook updates and gives me something more like what I'm after:

Although of course, the "description" column is missing the type name now.

Am I missing something, or is this a limitation of Storybook?

I'm assuming I can use the argTypes object to override it at a story level, but to me that seems to defeat the object of the autodocs feature, and gives me quite a lot more admin when creating Storybook stories.

Any assistance is greatly appreciated!

Additional information

I'm running the following versions (upgrading is possible, but organisationally challenging):
Storybook 9.1.1
React 16 🙄
Webpack 5

Create a reproduction

No response

[dosubot[bot]]

Hi @martynhoyer! I'm Dosu and I’m helping the storybook team.

This is a limitation of the default react-docgen parser, which uses AST/Babel-based pattern matching rather than the TypeScript compiler. It can't follow imported types across files, so your Status union gets collapsed to string [1].

Switching to react-docgen-typescript should fix this, since it invokes the full TypeScript compiler and can resolve imported types. In your .storybook/main.ts [2]:

const config: StorybookConfig = {
  // ...
  typescript: {
    reactDocgen: 'react-docgen-typescript',
    reactDocgenTypescriptOptions: {
      shouldExtractLiteralValuesFromEnum: true,
      shouldRemoveUndefinedFromOptional: true,
    },
  },
};

The trade-off is speed — react-docgen-typescript is slower (~2s overhead per component) since it spins up the TS compiler — but it handles imported union types, generics, and namespace imports that the default parser can't [3].

Give that a try and see if your Status union renders as a select control in the args table.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[martynhoyer]

Thought the AI was on to something there, but unfortunately not. We're already using react-docgen-typescript, but without those two additional config items, but adding those in doesn't seem to have helped.

[mg1986jp]

The dosubot answer is on the right track but incomplete. react-docgen-typescript does follow imports, but it needs the right tsconfig.json to resolve them correctly.

Two things to check:

1. Make sure your Storybook is pointed at the right tsconfig:

// .storybook/main.ts
export default {
  typescript: {
    reactDocgen: 'react-docgen-typescript',
    reactDocgenTypescriptOptions: {
      shouldExtractLiteralValuesFromEnum: true,
      shouldRemoveUndefinedFromOptional: true,
      // This is the key part — point to the tsconfig that includes your shared types
      tsconfigPath: './tsconfig.json',
    },
  },
};

2. Check how Status is defined in your shared file. react-docgen-typescript handles these differently:

// ✅ Works — union type alias
export type Status = "inProgress" | "completed" | "deleted";

// ✅ Works — enum
export enum Status { InProgress = "inProgress", Completed = "completed", Deleted = "deleted" }

// ❌ Might not resolve — re-exported from another file
export type { Status } from "./other-file";

If Status is re-exported through multiple files, react-docgen-typescript can lose track. Try a direct import path.

3. Quick workaround if the above doesn't help — you can force the control type per-component without manually listing values:

const meta = {
  component: HeaderCard,
  tags: ["autodocs"],
  argTypes: {
    status: {
      control: 'select',
      options: ["inProgress", "completed", "deleted"],
    },
  },
} satisfies Meta<typeof HeaderCard>;

Not ideal since it duplicates the values, but at least it's at the meta level so all stories inherit it.

What does the Status type definition look like in your shared file? And is there any path aliasing (like @shared/interfaces) that might confuse the docgen parser?