Addon Vitest: Support simple vite.config without defineConfig helper

[valentinpalkovic]

Closes #33409

What I did

This PR fixes a bug in the Vitest addon configuration validation where mergeConfig calls using plain object literals were incorrectly flagged as incompatible.

Before (broken):

// This was incorrectly flagged as incompatible
export default mergeConfig(viteConfig, {
  test: { name: 'node', environment: 'happy-dom' }
})

Before (worked):

// This worked correctly
export default mergeConfig(viteConfig, defineConfig({
  test: { name: 'node', environment: 'happy-dom' }
}))

Both configurations are semantically equivalent and should be supported.

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

1. Create a test project with a vitest.config.ts using mergeConfig with a plain object literal:

import { mergeConfig, coverageConfigDefaults } from 'vitest/config'
import viteConfig from './vite.config'

export default mergeConfig(
  viteConfig,
  {
    test: {
      name: 'node',
      environment: 'happy-dom',
    },
  }
)

2. Run Storybook init with the Vitest addon:

npx storybook@next init
# or add the addon to existing Storybook
npx storybook@next add @storybook/addon-test

3. Verify that:

   • The config file is correctly detected as compatible (no "unsupported format" error)
   • The Storybook project is properly added to the Vitest configuration
   • Running npx vitest --project=storybook works correctly

4. Test with defineConfig variant (should continue to work):

export default mergeConfig(
  viteConfig,
  defineConfig({
    test: { name: 'node', environment: 'happy-dom' }
  })
)

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-33694-sha-d9eaac60. Try it out in a new sandbox by running npx storybook@0.0.0-pr-33694-sha-d9eaac60 sandbox or in an existing project with npx storybook@0.0.0-pr-33694-sha-d9eaac60 upgrade.

More information

Published version	0.0.0-pr-33694-sha-d9eaac60
Triggered by	@valentinpalkovic
Repository	storybookjs/storybook
Branch	valentin/addon-vitest-support-simple-workspace-config
Commit	d9eaac60
Datetime	Wed Jan 28 14:55:14 UTC 2026 (1769612114)
Workflow run	21443036614

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=33694

Summary by CodeRabbit

• Tests

  • Added test coverage for configuration validation scenarios.

• Refactor

  • Improved configuration validation logic to handle additional configuration patterns.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[nx-cloud]

View your CI Pipeline Execution ↗ for commit d9eaac6

Command	Status	Duration	Result
nx run-many -t compile,check,knip,test,pretty-d...	✅ Succeeded	11m 16s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-01-29 16:22:14 UTC

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR extends Vitest configuration validation by generalizing the isSafeToExtendWorkspace utility to handle both defineConfig() calls and plain object literals, while adding support for merging multiple arguments in mergeConfig(). Four new test cases validate compatibility detection across these config patterns.

Changes

Cohort / File(s)	Summary
Vitest Configuration Validation code/core/src/cli/AddonVitestService.ts	Generalized isSafeToExtendWorkspace from accepting CallExpression to generic babel.types.Node; added logic to extract target object from either defineConfig({...}) or plain {...} literals; updated validation to handle multiple mergeConfig arguments by iterating through each with the updated utility
Vitest Configuration Validation Tests code/core/src/cli/AddonVitestService.test.ts	Added four new test cases under validateConfigFiles suite: mergeConfig with plain object literal, mergeConfig with defineConfig call, mergeConfig with multiple plain objects, and rejection of mergeConfig with invalid object argument

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• storybookjs/storybook#32753: Modifies Vitest config detection for mergeConfig and defineConfig with multi-argument inspection and object extraction logic
• storybookjs/storybook#32844: Generalizes extraction and validation of config object arguments for plain objects and defineConfig calls in the Vitest addon
• storybookjs/storybook#32717: Introduces/modifies the same AddonVitestService functions and test suite targeted by this PR

✨ Finishing touches

• 📝 Generate docstrings

---

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

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

code/core/src/cli/AddonVitestService.ts (1)

326-335: Handle plain-object default exports and avoid masking unsafe mergeConfig args.

Right now export default { ... } still falls through as invalid, and some(...) can accept configs where one mergeConfig object has an unsafe test.workspace because another object is safe. Consider (a) explicitly validating object-literal exports, and (b) validating all object-like mergeConfig args while ignoring non-object args.

🛠️ Proposed fix

-        if (this.isDefineConfigExpression(path.node.declaration)) {
-          isValidVitestConfig = this.isSafeToExtendWorkspace(path.node.declaration);
-        } else if (this.isMergeConfigExpression(path.node.declaration)) {
-          // the config could be anywhere in the mergeConfig call, so we need to check each argument
-          const mergeCall = path.node.declaration as CallExpression;
-          isValidVitestConfig = mergeCall.arguments.some((arg) =>
-            this.isSafeToExtendWorkspace(arg as CallExpression)
-          );
-        }
+        if (this.isDefineConfigExpression(path.node.declaration)) {
+          isValidVitestConfig = this.isSafeToExtendWorkspace(path.node.declaration);
+        } else if (babel.types.isObjectExpression(path.node.declaration)) {
+          isValidVitestConfig = this.isSafeToExtendWorkspace(path.node.declaration);
+        } else if (this.isMergeConfigExpression(path.node.declaration)) {
+          // the config could be anywhere in the mergeConfig call, so we need to check each argument
+          const mergeCall = path.node.declaration as CallExpression;
+          const objectArgs = mergeCall.arguments.filter(
+            (arg) => babel.types.isObjectExpression(arg) || babel.types.isCallExpression(arg)
+          );
+          isValidVitestConfig =
+            objectArgs.length > 0 && objectArgs.every((arg) => this.isSafeToExtendWorkspace(arg));
+        }

🧹 Nitpick comments (1)

code/core/src/cli/AddonVitestService.test.ts (1)

605-646: Add coverage for plain-object exports and unsafe mixed mergeConfig args.

These new cases are great for the mergeConfig shapes; after supporting object-literal default exports, please add:

• a positive case for export default { test: { ... } }, and
• a negative case where one mergeConfig object has test.workspace as a non-array while another object is safe.
  This will prevent false positives and lock in the intended safety behavior.