ArgsTable not exported as named 'ArgsTable' from '@storybook/addon-docs/blocks' when used with Vite/react-vite (prebundling issue)

[wkylin]

Context

• Storybook version used: 10.2.1 (tested)
• @storybook/addon-docs: 10.2.0 / 10.2.1 (installed via npm)
• Framework: @storybook/react-vite
• Environment: Vite (default Storybook builder-vite integration)

Description

When using MDX docs that import ArgsTable via:

import { ArgsTable } from '@storybook/addon-docs/blocks'

and then using in the MDX, Storybook throws an error at runtime:

The requested module '/@fs/.../.vite-cache/storybook/deps/@storybook_addon-docs_blocks.js?...' does not provide an export named 'ArgsTable'

Observed behavior

After Storybook/Vite runs, the prebundled file in .vite-cache/storybook/deps/@storybook_addon-docs_blocks.js contains an export list that includes "ArgsTable as PureArgsTable" (i.e. ArgsTable is renamed to PureArgsTable), but does not export a top-level named "ArgsTable" symbol. Because of that, the ESM named import import { ArgsTable } from '@storybook/addon-docs/blocks' fails in the browser:

Export list excerpt (from .vite-cache):

...
export {
  ...,
  ArgsTable as PureArgsTable,
  ...
}

Root cause hypothesis

This appears to be an interoperability/packaging issue where the Vite pre-bundling or the distributed module's export mapping doesn't provide the expected ArgsTable named export, only PureArgsTable. Consuming code (MDX docs & docs blocks) expects the ArgsTable export to be available from @storybook/addon-docs/blocks.

Short-term workarounds we used successfully

• Add @storybook/addon-docs and @storybook/addon-docs/blocks to Vite's optimizeDeps.exclude to prevent pre-bundling and force runtime resolution — this mitigates the issue in our setup.
• Use a local shim (project-level) that exposes a stable ArgsTable export (or pass explicit rows to a shim component) so the MDX docs don't break.

Request / Questions

• Is this behavior expected for some specific reason (e.g., intentional rename for internal API)?
• If not expected: could you confirm if the distribution (the ./dist/blocks entry) should provide a named export ArgsTable so tools like Vite don't lose that symbol during pre-bundling?
• Would you prefer we open a small PR to ensure ArgsTable is re-exported (alias) as part of the published blocks bundle, or is there a recommended configuration change on the consumer side that you endorse instead?

Repro steps (minimal)

1. Create a project with Storybook 10.x using @storybook/react-vite.
2. Add an MDX page that imports ArgsTable and uses <ArgsTable of={Component} /> (or just import { ArgsTable } from '@storybook/addon-docs/blocks' and use in MDX)
3. Start Storybook (npm run storybook) and observe the console error that the module does not provide an export named 'ArgsTable'.

I can provide a small reproduction repository or point to our project traces/logs if that helps. We implemented a working workaround (optimizeDeps.exclude + local shim) but think this warrants an upstream fix or guidance so projects relying on MDX/docs won't need shims.

Thank you — happy to help provide any additional details or a minimal repro.

[dosubot]

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

This isn't an intentional API change—ArgsTable is currently only exported as PureArgsTable from @storybook/addon-docs/blocks due to a temporary workaround in the codebase, as noted by a FIXME comment in the source. The maintainers recognize this export setup needs improvement and may address it in a future release, possibly via the package.json exports map (source).

For now, your workaround (excluding @storybook/addon-docs and @storybook/addon-docs/blocks from Vite's optimizeDeps or using a local shim) is the best approach. There’s no official config or upstream fix yet, but a PR to re-export ArgsTable as a named export would help future-proof the package and improve compatibility with Vite and MDX.

If you want to contribute, making ArgsTable a stable named export in the published blocks bundle would be a positive change. Until then, continue using your workaround to avoid breakage in MDX docs.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[wkylin]

Thanks for the quick clarification and the guidance, @dosubot and Storybook team — much appreciated.

We'll keep the local shim + optimizeDeps.exclude workaround for now to avoid breaking MDX docs in our repo. We're happy to open a small PR to make ArgsTable a stable named export in the published blocks bundle (for example a re-export alias so both ArgsTable and PureArgsTable exist), or to follow whatever approach you prefer (package.json exports map or explicit re-export in blocks entry).

Which approach would you prefer us to target in the PR? We can also attach a minimal repro repo to the issue if that helps accelerate verification.

Thanks again — we’re glad to help get this upstream-stable.

[dosubot]

The simplest and most direct fix is to add an explicit named export for ArgsTable in the blocks entry file (code/addons/docs/src/blocks.ts), while keeping PureArgsTable for backward compatibility. This approach aligns with the current code structure and the FIXME comment in the file, and avoids broader changes that could have unintended effects on consumers or tooling. Updating the package.json exports map could be considered later if more granular module export control is needed, but it's not required for this specific issue cite.

A minimal repro repo isn't strictly necessary for this well-understood export issue, but feel free to attach one if you think it will help with verification or CI checks.

Let me know if you need any more details or clarification!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[wkylin]

Hi team — I drafted a tiny compatibility patch that re-exports ArgsTable from the blocks entry so that consumers importing ArgsTable continue to work even when bundlers rename the internal implementation (e.g. PureArgsTable).

Patch (proposed):

*** Update File: code/addons/docs/src/blocks.ts
@@
 /*
  * Temporary compatibility re-export to ensure consumers importing
  * `ArgsTable` from `@storybook/addon-docs/blocks` continue to work
  * with bundlers that may rename or re-map internal exports (e.g.
  * Vite pre-bundling producing `PureArgsTable`).
  */

// Re-export the internal implementation as a stable, named export.
export { PureArgsTable as ArgsTable };

Rationale and testing notes are in the attached PR description below. This is intentionally a minimal, non-invasive change; if you prefer a different location (e.g., package exports map or build pipeline change) I can adapt the patch accordingly and open a full PR. Would you like me to submit the PR now?

(Attached PR description for review)

---

PR description:

"PR: re-export ArgsTable from @storybook/addon-docs/blocks

Summary
This small change re-exports the existing PureArgsTable implementation as a stable named export ArgsTable from code/addons/docs/src/blocks.ts.

Rationale
Some bundlers / pre-bundlers (for example Vite optimizeDeps) can alter the compiled modules and effectively remove/change named exports consumers expect, resulting in runtime errors like: The requested module '.../blocks.js' does not provide an export named 'ArgsTable'.

Change
Add a single line: export { PureArgsTable as ArgsTable } in code/addons/docs/src/blocks.ts (or the corresponding entry point that builds blocks bundle).

Testing & Notes
Unit tests for docs blocks should continue to pass; manual verification includes building with Vite and running Storybook + MDX that imports ArgsTable to ensure runtime import succeeds.

If maintainers are okay with this approach, I can open a formal PR with the change, tests and a short changelog entry."

[wkylin]

Update: I added a minimal unit test to the patch that verifies ArgsTable is exported and is an alias of PureArgsTable (code/addons/docs/src/__tests__/blocks.test.ts). I also ran a local simulation showing the re-export fixes the runtime import (local test suite passed).

Next steps: if you're happy with this approach I can open a formal PR with the patch, test, and a short note in the changelog. Otherwise I can adjust the patch to modify package exports instead if you prefer that approach.