Vue: Run docgen through component-meta project manager

[huang-julien]

Closes #

What I did

This PR implements ComponentMetaManager for Vue and use it for docgen. It is known that Volar has issues with ts reference/monorepo resolutions and that the API of vue component meta requires THE tsconfig for a vue file we want to analmyse.

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

---

Caution

This section is mandatory for all contributions. If you believe no manual test is necessary, please state so explicitly. Thanks!

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli-storybook/src/sandbox-templates.ts

• Declare whether manual QA will be needed for this PR during the next release, through qa:needed or qa:skip

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook publish.yml --field pr=<PR_NUMBER>

Summary by CodeRabbit

• New Features

  • Added Vue 3 component documentation generation with TypeScript project awareness.
  • Added support for extracting component metadata and Storybook arg types from Vue components.
  • Added an internal worker entry for processing Vue documentation requests.

• Tests

  • Added coverage for project references, Vue file resolution, metadata extraction, and Storybook fixtures.

[github-actions]

	Warnings
⚠️	This PR targets julien/vue_docgen_rendzerer. The default branch for contributions is next. Please make sure you are targeting the correct branch.

Generated by 🚫 dangerJS against f72e4de

[coderabbitai]

📝 Walkthrough

Walkthrough

Vue 3 adds a project manager backed by vue-component-meta, a worker-thread docgen provider, package build/export wiring, and fixtures/tests covering referenced TypeScript projects, Vue SFCs, metadata extraction, and inferred projects.

Changes

Vue 3 docgen integration

Layer / File(s)	Summary
Vue project manager and checker lifecycle code/renderers/vue3/src/docgen/vue-project-manager.ts	Adds Vue-specific configured and inferred projects, checker file tracking, change handling, project resolution, and heap-pressure recycling.
Docgen worker provider and package wiring code/renderers/vue3/src/docgen/docgen-worker.ts, code/renderers/vue3/build-config.ts, code/renderers/vue3/package.json	Adds lazy Vue docgen middleware, builds matching story payloads, and exposes the worker through the package exports and Node build configuration.
Referenced-project fixtures and extraction tests code/renderers/vue3/src/docgen/__testfixtures__/references/*, code/renderers/vue3/src/docgen/vue-project-manager.test.ts	Adds Vue component and TypeScript project-reference fixtures and tests project selection, SFC inclusion, extracted argTypes, structured cloning, and inferred projects.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant StoryEntry
  participant createDocgenProvider
  participant VueComponentMetaManager
  participant buildDocgenPayload
  participant nextDocgen
  StoryEntry->>createDocgenProvider: send docgen request
  createDocgenProvider->>VueComponentMetaManager: get checker for component
  VueComponentMetaManager-->>buildDocgenPayload: provide Vue checker
  buildDocgenPayload->>nextDocgen: merge extracted payload with downstream result

Loading

Possibly related PRs

• storybookjs/storybook#35324: Introduces the renderer-specific docgen worker/provider composition pattern used by this Vue integration.
• storybookjs/storybook#35657: Adds the core component-meta project abstractions extended by the Vue project manager.
• storybookjs/storybook#35665: Provides renderer-level docgen extraction utilities used by the new Vue worker and project manager.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Fix failing CI checks

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (3)

code/renderers/vue3/src/docgen/vue-project-manager.test.ts (2)

33-36: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Assert checker/docgen behavior instead of parsed-command-line internals.

Both assertions couple the suite to the project manager’s direct-include implementation. Exercise getCheckerForFile() or payload extraction for each fixture and assert metadata is available.

• code/renderers/vue3/src/docgen/vue-project-manager.test.ts#L33-L36: replace the fileNames assertion with successful checker-backed extraction for the referenced project.
• code/renderers/vue3/src/docgen/vue-project-manager.test.ts#L73-L82: replace the fileNames assertion with successful checker-backed extraction for the no-include Vue fixture.

As per coding guidelines, tests should verify public contracts and externally observable side effects rather than private implementation details.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@code/renderers/vue3/src/docgen/vue-project-manager.test.ts` around lines 33 -
36, Replace the parsed-command-line fileNames assertions in
code/renderers/vue3/src/docgen/vue-project-manager.test.ts at lines 33-36 and
73-82 with public-contract checks: for each fixture, call getCheckerForFile() or
the existing payload-extraction path and assert that metadata is successfully
returned, including the no-include Vue fixture.

Source: Coding guidelines

---

85-92: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Use the established memfs test setup.

This writes an undeleted real temporary directory and makes the test dependent on host filesystem behavior. Seed the virtual SFC with memfs, reset vol in beforeEach, and use the established spy-redirection pattern.

As per coding guidelines, filesystem tests using node:fs or node:fs/promises must use memfs, reset vol in beforeEach, and avoid real temporary directories.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@code/renderers/vue3/src/docgen/vue-project-manager.test.ts` around lines 85 -
92, Update the test setup around “serves files no tsconfig covers from the
inferred project” to use the established memfs virtual filesystem instead of
node:fs/promises, mkdtemp, and a real temporary directory. Reset vol in
beforeEach, seed Loose.vue through memfs, and apply the existing spy-redirection
pattern so filesystem access is fully virtualized.

Source: Coding guidelines

code/renderers/vue3/src/docgen/vue-project-manager.ts (1)

158-171: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Redundant tsconfig re-parse per created file in a batch.

For every 'created' change in the batch, getCommandLineFn?.() is invoked again (Line 161), re-running the full parseCommandLine (multiple disk reads + JSON parses per earlier review of Lines 207-231). A batch of several newly created files (e.g. after a branch switch or dependency install touching watched paths) triggers that many redundant re-parses in a single onFilesChanged call.

♻️ Proposed fix: fetch the command line once per batch

   onFilesChanged(changes: FileChange[]): void {
+    let commandLine: ts.ParsedCommandLine | undefined;
+    let commandLineFetched = false;
     for (const { filePath, type } of changes) {
       const fileName = normalize(filePath);
       ...
       // created:
-      const commandLine = this.getCommandLineFn?.();
+      if (!commandLineFetched) {
+        commandLine = this.getCommandLineFn?.();
+        commandLineFetched = true;
+      }
       if (commandLine) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@code/renderers/vue3/src/docgen/vue-project-manager.ts` around lines 158 -
171, Update the onFilesChanged batch handling to obtain the command line once
before iterating over created files, then reuse that value for each file’s
inclusion check and this.commandLine assignment. Remove the per-file
getCommandLineFn invocation while preserving adoption only for files present in
the refreshed commandLine.fileNames.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@code/renderers/vue3/src/docgen/docgen-worker.ts`:
- Around line 55-68: Wrap the per-request extraction flow in the worker around
buildDocgenPayload, including manager.getCheckerForFile, with try/catch so
checker, tsconfig, and filesystem failures fall back to nextDocgen(input).
Preserve the existing heap-pressure recycling behavior and continue using the
successful payload path when extraction completes normally.

In `@code/renderers/vue3/src/docgen/vue-project-manager.test.ts`:
- Around line 22-25: Update the comment above the Vue project manager test to
retain only the maintenance rationale for walking the TypeScript reference chain
and locating the sub-config covering the component. Remove the description of
the previous fallback behavior, the “single-checker path” history, and the
upstream issue reference.

In `@code/renderers/vue3/src/docgen/vue-project-manager.ts`:
- Around line 100-130: Update ensureFresh so a file with no previous mtime is
refreshed immediately rather than only recording its current mtime. Reuse the
existing tryReadFile and checker.updateFile flow for this first sighting, then
store the resulting mtime; preserve the current behavior for unchanged and
previously tracked files.

---

Nitpick comments:
In `@code/renderers/vue3/src/docgen/vue-project-manager.test.ts`:
- Around line 33-36: Replace the parsed-command-line fileNames assertions in
code/renderers/vue3/src/docgen/vue-project-manager.test.ts at lines 33-36 and
73-82 with public-contract checks: for each fixture, call getCheckerForFile() or
the existing payload-extraction path and assert that metadata is successfully
returned, including the no-include Vue fixture.
- Around line 85-92: Update the test setup around “serves files no tsconfig
covers from the inferred project” to use the established memfs virtual
filesystem instead of node:fs/promises, mkdtemp, and a real temporary directory.
Reset vol in beforeEach, seed Loose.vue through memfs, and apply the existing
spy-redirection pattern so filesystem access is fully virtualized.

In `@code/renderers/vue3/src/docgen/vue-project-manager.ts`:
- Around line 158-171: Update the onFilesChanged batch handling to obtain the
command line once before iterating over created files, then reuse that value for
each file’s inclusion check and this.commandLine assignment. Remove the per-file
getCommandLineFn invocation while preserving adoption only for files present in
the refreshed commandLine.fileNames.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 298dac4d-be62-4596-bded-fe63d967b6f4

📥 Commits

Reviewing files that changed from the base of the PR and between f284601 and 9b65bd2.

⛔ Files ignored due to path filters (1)

• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (9)

• code/renderers/vue3/build-config.ts
• code/renderers/vue3/package.json
• code/renderers/vue3/src/docgen/__testfixtures__/references/src/RefButton.stories.ts
• code/renderers/vue3/src/docgen/__testfixtures__/references/src/RefButton.vue
• code/renderers/vue3/src/docgen/__testfixtures__/references/tsconfig.app.json
• code/renderers/vue3/src/docgen/__testfixtures__/references/tsconfig.json
• code/renderers/vue3/src/docgen/docgen-worker.ts
• code/renderers/vue3/src/docgen/vue-project-manager.test.ts
• code/renderers/vue3/src/docgen/vue-project-manager.ts

[storybook-app-bot]

Package Benchmarks

^{Commit: df12640, ran on 4 August 2026 at 08:37:15 UTC}

The following packages have significant changes to their size or dependencies:

@storybook/vue3-vite

	Before	After	Difference
Dependency count	103	102	🎉 -1 🎉
Self size	30 KB	30 KB	🎉 -4 B 🎉
Dependency size	43.12 MB	19.52 MB	🎉 -23.60 MB 🎉
Bundle Size Analyzer	Link	Link

@storybook/vue3

	Before	After	Difference
Dependency count	90	90	0
Self size	75 KB	97 KB	🚨 +22 KB 🚨
Dependency size	18.08 MB	18.08 MB	🚨 +176 B 🚨
Bundle Size Analyzer	Link	Link

[valentinpalkovic]

Second review pass. For transparency: I paired this with an AI code-quality review (the Cursor "thermo-nuclear code quality review" skill), then filtered it down to only the findings that are genuinely new on top of my earlier comments. A couple are deliberately low-confidence questions rather than blockers - flagged inline. 🙂