Addon-Vitest: Streamline vite(st) config detection across init and postinstall

[valentinpalkovic]

Closes #

What I did

Extracted the shared AST helper functions for analyzing Vitest/Vite config files into a new vitest-config-helpers.ts module inside storybook/internal/babel. Previously, both AddonVitestService (used during storybook init) and updateVitestFile (used during the postinstall script) each had their own copy of helpers like isDefineConfigLike, getConfigObjectFromMergeArg, getEffectiveMergeConfigCall, and getTargetConfigObject.

This PR:

• Creates code/core/src/babel/vitest-config-helpers.ts with the shared helpers, plus two new top-level functions canUpdateVitestConfigFile and canUpdateVitestWorkspaceFile
• Exports all new helpers from storybook/internal/babel
• Removes the duplicate implementations from updateVitestFile.ts and AddonVitestService.ts, replacing them with imports
• Adds comprehensive unit tests covering all supported and unsupported config patterns

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!

This is a pure refactor that moves code without changing behavior. The shared helpers are tested via unit tests in vitest-config-helpers.test.ts. The existing integration paths (storybook init and the addon postinstall) continue to use the same logic, just from a shared location.

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

• 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 pull request has been released as version 0.0.0-pr-34193-sha-7695cbc2. Try it out in a new sandbox by running npx storybook@0.0.0-pr-34193-sha-7695cbc2 sandbox or in an existing project with npx storybook@0.0.0-pr-34193-sha-7695cbc2 upgrade.

More information

Published version	0.0.0-pr-34193-sha-7695cbc2
Triggered by	@valentinpalkovic
Repository	storybookjs/storybook
Branch	valentin/streamline-config-validation-detection-across-init-and-postinstall
Commit	7695cbc2
Datetime	Wed Mar 18 10:19:43 UTC 2026 (1773829183)
Workflow run	23239883007

To request a new release of this pull request, mention the @storybookjs/core team.

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

Summary by CodeRabbit

• Tests

  • Expanded coverage for Vitest config and workspace detection across many real-world and edge-case patterns, including positive and negative cases for supported/unupported export shapes.

• Refactor

  • Centralized Vitest validation into shared detection helpers and widened recognized config shapes (including plain object exports); explicitly reject unsupported arrow-function wrappers.

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 4ef9a1e

Command	Status	Duration	Result
nx run-many -t compile -c production --parallel=1	✅ Succeeded	5m 18s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-03-20 11:20:10 UTC

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c1543416-9e19-449d-b1e7-35e6dee47ac8

📥 Commits

Reviewing files that changed from the base of the PR and between befc63a and 4ef9a1e.

📒 Files selected for processing (3)

• code/addons/vitest/src/updateVitestFile.ts
• code/core/src/babel/vitest-config-helpers.test.ts
• code/core/src/cli/AddonVitestService.test.ts

🚧 Files skipped from review as they are similar to previous changes (3)

• code/core/src/babel/vitest-config-helpers.test.ts
• code/addons/vitest/src/updateVitestFile.ts
• code/core/src/cli/AddonVitestService.test.ts

---

📝 Walkthrough

Walkthrough

Extracts Vitest/Vite AST helpers into a new shared module, re-exports them from core babel, refactors addon-vitest and AddonVitestService to consume those helpers, adds tests for the helpers, and removes an unused import.

Changes

Cohort / File(s)	Summary
Vitest config helpers & tests code/core/src/babel/vitest-config-helpers.ts, code/core/src/babel/vitest-config-helpers.test.ts	Adds a new shared AST helper module that detects/unwraps/validates Vitest/Vite config and workspace shapes and a comprehensive test suite covering many export/merge patterns.
Babel public exports code/core/src/babel/index.ts	Re-exports seven helpers from vitest-config-helpers to expose them via the core babel API.
Addon Vitest file updates code/addons/vitest/src/updateVitestFile.ts	Replaces local helper implementations with imports from core babel helpers while keeping merge/template update logic and mergeProperties intact.
Addon Vitest cleanup code/addons/vitest/src/postinstall.ts	Removes an unused existsSync import from node:fs.
AddonVitestService refactor & tests code/core/src/cli/AddonVitestService.ts, code/core/src/cli/AddonVitestService.test.ts	Replaces in-file validation logic with canUpdateVitestConfigFile/canUpdateVitestWorkspaceFile helpers and updates tests to accept additional mergeConfig/defineConfig patterns and add arrow-function negative case.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• Addon Vitest: Support modifying mergeConfig on addon setup #32753: Related — touches Vitest config update logic and shared vitest-config helpers used by updateVitestFile.
• Addon Vitest: Support simple vite.config without defineConfig helper #33694: Related — modifies AddonVitestService/config validation to recognise plain-object and mergeConfig patterns, overlapping test and validation changes.
• Addon-Vitest: Support vite/vitest config with deferred export #33755: Related — overlaps on resolving deferred/default-exported Vitest/Vite configs and use of getTargetConfigObject in update logic.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

📝 Coding Plan

• Generate coding plan for human review comments

---

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

[yannbf]

Code looks and works well, so LGTM but I feel like it's weird to have vitest helpers exposed as APIs from storybook/internal/babel. Some of these utilities are generic enough and could be nice to have, but vitest specific things do feel a little weird to me. Last time we had vitest specific code (transformer) we moved it to csf-tools.

[valentinpalkovic]

Code looks and works well, so LGTM, but I feel like it's weird to have vitest helpers exposed as APIs from storybook/internal/babel. Some of these utilities are generic enough and could be nice to have, but vitest specific things do feel a little weird to me. Last time we had a specific code (transformer), we moved it to csf-tools.

I kind of share the same feeling (but not too strongly). I am okay to move it into whatever core package you prefer. Since it is heavily based on Babel, I assumed storybook/internal/babel is the right place for it. If you feel strongly about it, then I can still move it to e.g. csf-tools.

[storybook-app-bot]

Package Benchmarks

^{Commit: 4ef9a1e, ran on 20 March 2026 at 11:18:12 UTC}

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

storybook

	Before	After	Difference
Dependency count	49	49	0
Self size	20.45 MB	20.46 MB	🚨 +13 KB 🚨
Dependency size	16.54 MB	16.54 MB	🎉 -2 B 🎉
Bundle Size Analyzer	Link	Link

@storybook/react-native-web-vite

	Before	After	Difference
Dependency count	121	124	🚨 +3 🚨
Self size	30 KB	30 KB	🎉 -5 B 🎉
Dependency size	23.54 MB	23.78 MB	🚨 +240 KB 🚨
Bundle Size Analyzer	Link	Link

@storybook/cli

	Before	After	Difference
Dependency count	183	183	0
Self size	779 KB	779 KB	🎉 -71 B 🎉
Dependency size	67.65 MB	67.66 MB	🚨 +12 KB 🚨
Bundle Size Analyzer	Link	Link

@storybook/codemod

	Before	After	Difference
Dependency count	176	176	0
Self size	32 KB	32 KB	🎉 -2 B 🎉
Dependency size	66.17 MB	66.19 MB	🚨 +13 KB 🚨
Bundle Size Analyzer	Link	Link

create-storybook

	Before	After	Difference
Dependency count	50	50	0
Self size	1.05 MB	1.04 MB	🎉 -2 KB 🎉
Dependency size	36.99 MB	37.01 MB	🚨 +13 KB 🚨
Bundle Size Analyzer	node	node

[yannbf]

Code looks and works well, so LGTM, but I feel like it's weird to have vitest helpers exposed as APIs from storybook/internal/babel. Some of these utilities are generic enough and could be nice to have, but vitest specific things do feel a little weird to me. Last time we had a specific code (transformer), we moved it to csf-tools.

I kind of share the same feeling (but not too strongly). I am okay to move it into whatever core package you prefer. Since it is heavily based on Babel, I assumed storybook/internal/babel is the right place for it. If you feel strongly about it, then I can still move it to e.g. csf-tools.

My perspective is that internal/babel should hold core utilities that are low-level only (which is how it stands now). One alternative would be to make the utilities more low-level/generic and leave them in internal/babel, but we can just move to csf-tools and call it a day, then the PR is good to merge 👍

[valentinpalkovic]

csf-tools, on the other hand, are about "CSF tools". The helpers we talk about aren't about story configs or main/preview configs at all. Don't you think that by taking the domain into consideration, csf-tools is a bad place to put them?