Addon-Vitest: Refactor Vitest setup to eliminate the need for a dedicated setup file#34025
Conversation
|
View your CI Pipeline Execution ↗ for commit 5dbf094
☁️ Nx Cloud last updated this comment at |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a plugin-managed internal Vitest setup file that injects Storybook project annotations via a virtual builder module, exposes it in the Vitest addon build exports, removes prior postinstall/sandbox-generated setup-file logic and template Changes
Sequence Diagram(s)sequenceDiagram
participant Plugin as Vitest Plugin
participant Builder as virtual:/@storybook/builder-vite
participant Vitest as Vitest Runner
participant FS as Filesystem
Plugin->>Vitest: read test config (including setupFiles)
Plugin->>FS: resolve existing setupFiles paths
Plugin->>Plugin: call requiresProjectAnnotations(testConfig, options, isCSF4)
Plugin->>Builder: import virtual:/@storybook/builder-vite/project-annotations.js
Builder-->>Plugin: provide getProjectAnnotations()
alt needs annotations
Plugin->>FS: include internal setup file (setup-file-with-project-annotations)
Plugin->>Vitest: inject internal setup file into final setupFiles
Vitest->>FS: load & execute setup-file-with-project-annotations
Note right of Vitest: setup file calls setProjectAnnotations(getProjectAnnotations())
else no annotations needed
Plugin->>Vitest: leave setupFiles unchanged (or preserve existing entries)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
code/addons/vitest/src/vitest-plugin/index.ts (1)
329-334:⚠️ Potential issue | 🟠 MajorPreserve array-form
test.setupFileswhen merging configs.The current logic only checks for
setupFilesas a string and filters to false for array form, silently dropping user-provided setup files when configured as an array. Vitest accepts bothstringandstring[], so both forms must be preserved.The suggested fix correctly handles both types by normalizing them to an array before merging:
Suggested implementation
+const existingSetupFiles = Array.isArray(nonMutableInputConfig.test?.setupFiles) + ? nonMutableInputConfig.test.setupFiles + : typeof nonMutableInputConfig.test?.setupFiles === 'string' + ? [nonMutableInputConfig.test.setupFiles] + : []; + const baseConfig: Omit<ViteUserConfig, 'plugins'> = { cacheDir: resolvePathInStorybookCache('sb-vitest', projectId), test: { expect: { requireAssertions: false }, setupFiles: [ ...internalSetupFiles, - // if the existing setupFiles is a string, we have to include it otherwise we're overwriting it - typeof nonMutableInputConfig.test?.setupFiles === 'string' && - nonMutableInputConfig.test?.setupFiles, - ].filter(Boolean) as string[], + ...existingSetupFiles, + ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@code/addons/vitest/src/vitest-plugin/index.ts` around lines 329 - 334, The merge currently only preserves nonMutableInputConfig.test?.setupFiles when it's a string, dropping array-form values; update the merge for setupFiles in the vitest plugin to normalize nonMutableInputConfig.test?.setupFiles to an array (using Array.isArray or similar) before spreading so both string and string[] are preserved and concatenated with internalSetupFiles; locate the setupFiles merge expression (referencing setupFiles, internalSetupFiles, and nonMutableInputConfig.test?.setupFiles) and replace the conditional with a normalized array merge.
🧹 Nitpick comments (1)
scripts/build/utils/generate-bundle.ts (1)
210-213: Use explicit null-coalescing inflatMapinstead of relying onfilter(Boolean)for type safety in strict mode.In TypeScript strict mode,
filter(Boolean)does not narrow union types becauseBooleanis a regular function, not a type predicate. The array remains(string | undefined)[]after filtering, causing type inconsistency. The refactor usingflatMap((entry) => entry.external ?? [])properly narrows tostring[]and is clearer under strict typing.♻️ Suggested refactor
external: [ ...(sharedOptions.external as string[]), - ...(entries.browser.flatMap((entry) => entry.external) ?? []), - ].filter(Boolean), + ...entries.browser.flatMap((entry) => entry.external ?? []), + ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/build/utils/generate-bundle.ts` around lines 210 - 213, The current construction uses entries.browser.flatMap((entry) => entry.external) and then .filter(Boolean), which doesn't narrow types under TS strict mode; change the flatMap to explicitly coalesce undefined: use entries.browser.flatMap((entry) => entry.external ?? []) so the result is string[] (alongside sharedOptions.external) and then you can remove the reliance on filter(Boolean); update the external array assembly (the spread of sharedOptions.external and the entries.flatMap) so the union is explicitly narrowed to string[].
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@code/addons/vitest/src/vitest-plugin/index.ts`:
- Around line 329-334: The merge currently only preserves
nonMutableInputConfig.test?.setupFiles when it's a string, dropping array-form
values; update the merge for setupFiles in the vitest plugin to normalize
nonMutableInputConfig.test?.setupFiles to an array (using Array.isArray or
similar) before spreading so both string and string[] are preserved and
concatenated with internalSetupFiles; locate the setupFiles merge expression
(referencing setupFiles, internalSetupFiles, and
nonMutableInputConfig.test?.setupFiles) and replace the conditional with a
normalized array merge.
---
Nitpick comments:
In `@scripts/build/utils/generate-bundle.ts`:
- Around line 210-213: The current construction uses
entries.browser.flatMap((entry) => entry.external) and then .filter(Boolean),
which doesn't narrow types under TS strict mode; change the flatMap to
explicitly coalesce undefined: use entries.browser.flatMap((entry) =>
entry.external ?? []) so the result is string[] (alongside
sharedOptions.external) and then you can remove the reliance on filter(Boolean);
update the external array assembly (the spread of sharedOptions.external and the
entries.flatMap) so the union is explicitly narrowed to string[].
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 429cc422-1f74-4eba-ab41-07f14d6a60f2
📒 Files selected for processing (15)
code/addons/vitest/build-config.tscode/addons/vitest/package.jsoncode/addons/vitest/src/postinstall.test.tscode/addons/vitest/src/postinstall.tscode/addons/vitest/src/updateVitestFile.test.tscode/addons/vitest/src/vitest-plugin/index.tscode/addons/vitest/src/vitest-plugin/setup-file-with-project-annotations.tscode/addons/vitest/src/vitest-plugin/utils.tscode/addons/vitest/templates/vitest.config.3.2.template.tscode/addons/vitest/templates/vitest.config.4.template.tscode/addons/vitest/templates/vitest.config.template.tscode/addons/vitest/templates/vitest.workspace.template.tsscripts/build/utils/entry-utils.tsscripts/build/utils/generate-bundle.tsscripts/tasks/sandbox-parts.ts
💤 Files with no reviewable changes (6)
- code/addons/vitest/templates/vitest.config.3.2.template.ts
- code/addons/vitest/templates/vitest.config.4.template.ts
- code/addons/vitest/templates/vitest.workspace.template.ts
- code/addons/vitest/templates/vitest.config.template.ts
- code/addons/vitest/src/postinstall.test.ts
- code/addons/vitest/src/postinstall.ts
…e and streamline project annotations handling
valentinpalkovic
force-pushed
the
valentin/remove-need-for-setup-file
branch
from
4bdbd87 to
4137924
Compare
…esence before transformation
…nd update documentation accordingly
…nnotations function
valentinpalkovic
requested review from
jonniebigodes and
kylegach
as code owners
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@code/addons/vitest/src/vitest-plugin/index.ts`:
- Around line 316-324: The code passes previewOrConfigFile (an absolute
filesystem path) into import.meta.resolve inside the internalSetupFiles
construction, which fails because import.meta.resolve expects a module specifier
or file: URL; update the logic in the internalSetupFiles mapping to detect if
previewOrConfigFile is an absolute path and, for that case, convert it to a
file: URL (e.g., via pathToFileURL) and then call fileURLToPath, or bypass
import.meta.resolve and directly use
fileURLToPath(pathToFileURL(previewOrConfigFile)); keep using
import.meta.resolve for bare/relative specifiers and ensure the symbols
internalSetupFiles, previewOrConfigFile, import.meta.resolve, and fileURLToPath
are the points of change.
In `@code/addons/vitest/src/vitest-plugin/utils.ts`:
- Around line 42-52: The unguarded readFileSync inside the
hasStorybookAnnotations computation can throw if a setup file is
missing/unreadable; wrap the readFileSync call in a try/catch (or check
existence) so that failures simply return false for that entry instead of
propagating an exception. Update the hasStorybookAnnotations logic (referencing
userSetupFiles, hasStorybookAnnotations, readFileSync, setupFileContent,
finalOptions.configDir) so any read or access error for a setupFile is caught
and treated as “no annotations” (return false) to allow graceful config
detection.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ffd87e1e-337f-43fe-980a-a0155692cb14
📒 Files selected for processing (22)
code/addons/vitest/build-config.tscode/addons/vitest/package.jsoncode/addons/vitest/src/postinstall.test.tscode/addons/vitest/src/postinstall.tscode/addons/vitest/src/updateVitestFile.test.tscode/addons/vitest/src/vitest-plugin/index.tscode/addons/vitest/src/vitest-plugin/setup-file-with-project-annotations.tscode/addons/vitest/src/vitest-plugin/utils.tscode/addons/vitest/templates/vitest.config.3.2.template.tscode/addons/vitest/templates/vitest.config.4.template.tscode/addons/vitest/templates/vitest.config.template.tscode/addons/vitest/templates/vitest.workspace.template.tscode/lib/cli-storybook/src/automigrate/fixes/addon-a11y-addon-test.tsdocs/_snippets/storybook-addon-a11y-test-setup.mddocs/writing-tests/accessibility-testing.mdxdocs/writing-tests/integrations/vitest-addon/index.mdxscripts/build/utils/entry-utils.tsscripts/build/utils/generate-bundle.tsscripts/tasks/sandbox-parts.tstest-storybooks/portable-stories-kitchen-sink/react-vitest-3/.storybook/vitest.setup.tstest-storybooks/portable-stories-kitchen-sink/react/.storybook/vitest.setup.tstest-storybooks/yarn-pnp/.storybook/vitest.setup.ts
💤 Files with no reviewable changes (9)
- docs/writing-tests/integrations/vitest-addon/index.mdx
- test-storybooks/yarn-pnp/.storybook/vitest.setup.ts
- code/addons/vitest/src/postinstall.test.ts
- code/addons/vitest/templates/vitest.config.template.ts
- code/addons/vitest/src/postinstall.ts
- code/addons/vitest/templates/vitest.workspace.template.ts
- code/addons/vitest/templates/vitest.config.4.template.ts
- docs/_snippets/storybook-addon-a11y-test-setup.md
- code/addons/vitest/templates/vitest.config.3.2.template.ts
🚧 Files skipped from review as they are similar to previous changes (3)
- scripts/build/utils/entry-utils.ts
- scripts/build/utils/generate-bundle.ts
- code/addons/vitest/src/vitest-plugin/setup-file-with-project-annotations.ts
| const internalSetupFiles = ( | ||
| [ | ||
| '@storybook/addon-vitest/internal/setup-file', | ||
| areProjectAnnotationRequired && | ||
| '@storybook/addon-vitest/internal/setup-file-with-project-annotations', | ||
| isCSF4 && previewOrConfigFile, | ||
| ].filter(Boolean) as string[] | ||
| ).map((filePath) => fileURLToPath(import.meta.resolve(filePath))); | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Node.js import.meta.resolve absolute filesystem path Windows behavior
💡 Result:
import.meta.resolve() in Node.js returns an absolute URL string, not a native filesystem path. On Windows, local files resolve to file:///C:/... (forward slashes, file: scheme). Node documents this explicitly: ESM “are resolved and cached as URLs”, and import.meta.resolve(specifier) “returns the absolute URL string”. [1]
So if you need an absolute Windows path like C:\dir\file.js, convert the returned file URL with fileURLToPath():
import { fileURLToPath } from "node:url";
const url = import.meta.resolve("./dep.js"); // e.g. "file:///C:/proj/dep.js" on Windows
const path = fileURLToPath(url); // "C:\\proj\\dep.js"Avoid new URL(...).pathname on Windows, because it produces paths like /C:/Users/... (leading slash), which are not valid Win32 paths; fileURLToPath() handles this correctly. [2]
Sources: Node.js ESM docs (import.meta.resolve, URL-based resolution) [1], Windows path conversion caveat and fileURLToPath() example [2].
[1] (nodejs.org)
[2] (bero.dev)
Citations:
- 1: https://nodejs.org/download/nightly/v26.0.0-nightly2026022776215dc993/docs/api/esm.html
- 2: https://bero.dev/dont-use-url-to-construct-paths-in-node-js/
🌐 Web query:
Node.js ESM import.meta.resolve documentation specification
💡 Result:
import.meta.resolve is not part of the ECMAScript (TC39) language spec; TC39 only standardizes the import.meta syntax and leaves its properties up to the host environment [4], [5]. In practice, the closest “specification” is split between:
- WHATWG HTML Standard (the web platform / browsers): defines the underlying “resolve a module specifier” algorithm (including import maps) that host resolution APIs build on [2]. MDN notes that the HTML standard defines
import.meta.resolveusing this module specifier resolution machinery [3]. - Node.js documentation (Node’s host behavior): Node documents
import.meta.resolve(specifier)as returning the resolved absolute URL string using Node’s full ESM resolution rules (including package resolution/exports), and documents caveats and a Node-only extra parameter behind a flag [1]. Node also publishes its ESM resolution algorithm specification (e.g.,ESM_RESOLVE) in the same ESM docs page [1].
Primary references
- Node.js ESM docs (
import.meta.resolve+ “Resolution algorithm specification”) [1] - WHATWG HTML Standard: “resolve a module specifier” algorithm [2]
- MDN:
import.meta.resolve()(and its relationship to HTML / not being in ECMAScript) [3] - MDN:
import.meta(host-defined properties) [4] - TC39
import.metaproposal/spec text (syntax only) [5]
Sources: [1] (nodejs.org) [2] (html.spec.whatwg.org) [3] (developer.mozilla.org) [4] (developer.mozilla.org) [5] (tc39.es)
Citations:
- 1: https://nodejs.org/api/esm.html
- 2: https://html.spec.whatwg.org/multipage/webappapis.html
- 3: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta/resolve?utm_source=openai
- 4: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta?utm_source=openai
- 5: https://tc39.es/proposal-import-meta/?utm_source=openai
🌐 Web query:
import.meta.resolve accept absolute filesystem path input fails
💡 Result:
import.meta.resolve() resolves module specifiers, not raw OS filesystem paths. An absolute path like /Users/me/app/foo.js (or C:\...) is not a valid module specifier/URL, so resolution fails. import.meta.resolve() accepts relative specifiers (./foo.js), bare specifiers (pkg), or an absolute URL (not an absolute filesystem path). [1][2]
Fix (Node.js): convert the path to a file: URL first:
import { pathToFileURL, fileURLToPath } from "node:url";
const fsPath = "/Users/me/app/foo.js"; // or "C:\\Users\\me\\app\\foo.js"
const url = pathToFileURL(fsPath).href; // "file:///Users/me/app/foo.js"
const resolvedUrl = import.meta.resolve(url);
const resolvedPath = fileURLToPath(resolvedUrl);If you meant “resolve relative to this module”, pass a relative specifier:
const resolvedUrl = import.meta.resolve("./foo.js");[2]
Sources: MDN import.meta.resolve() (accepted inputs) [1]; Node.js ESM docs for import.meta.resolve() (returns an absolute URL string; module-relative resolution) [2].
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta/resolve
[2] https://nodejs.org/download/release/v23.11.1/docs/api/esm.html#importmetaresolvespecifier
🌐 Web query:
Node.js import.meta.resolve expects module specifier not file path
💡 Result:
import.meta.resolve() takes a module specifier (the same kind of string you’d put in an import ... from "..."), not an OS file path like /tmp/x.js or C:\x.js. In Node.js, valid specifiers are typically relative ('./dep.js'), bare ('some-package'), or absolute URL specifiers such as a file: URL ('file:///opt/app/dep.js'). [1]
If you currently have a filesystem path, convert it to a file: URL first
import { pathToFileURL } from 'node:url';
const filePath = '/tmp/dep.js';
const specifier = pathToFileURL(filePath).href;
const resolved = import.meta.resolve(specifier);Node explicitly recommends using url.pathToFileURL() when importing/resolving from a path (because ESM resolution is URL-based and involves encoding rules). [1]
If you meant “resolve a file relative to this module”
const resolved = import.meta.resolve('./dep.js');Relative specifiers must include the file extension in Node’s ESM. [1]
Sources: Node.js ESM docs on specifier types, URL-based resolution, and import.meta.resolve(). [1]
[1] https://nodejs.org/download/nightly/v26.0.0-nightly2026022776215dc993/docs/api/esm.html
Passing absolute filesystem paths to import.meta.resolve() will fail.
import.meta.resolve() expects module specifiers (relative like './foo', bare like 'pkg', or file: URLs), not raw filesystem paths. The previewOrConfigFile value is an absolute path, so it cannot be passed directly to import.meta.resolve(). When CSF4 is enabled and a preview/config file is present, this will cause a runtime failure.
💡 Proposed fix
- const internalSetupFiles = (
- [
- '@storybook/addon-vitest/internal/setup-file',
- areProjectAnnotationRequired &&
- '@storybook/addon-vitest/internal/setup-file-with-project-annotations',
- isCSF4 && previewOrConfigFile,
- ].filter(Boolean) as string[]
- ).map((filePath) => fileURLToPath(import.meta.resolve(filePath)));
+ const internalSetupFiles = [
+ '@storybook/addon-vitest/internal/setup-file',
+ areProjectAnnotationRequired &&
+ '@storybook/addon-vitest/internal/setup-file-with-project-annotations',
+ isCSF4 && previewOrConfigFile,
+ ]
+ .filter((filePath): filePath is string => Boolean(filePath))
+ .map((filePath) =>
+ path.isAbsolute(filePath) ? filePath : fileURLToPath(import.meta.resolve(filePath))
+ );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@code/addons/vitest/src/vitest-plugin/index.ts` around lines 316 - 324, The
code passes previewOrConfigFile (an absolute filesystem path) into
import.meta.resolve inside the internalSetupFiles construction, which fails
because import.meta.resolve expects a module specifier or file: URL; update the
logic in the internalSetupFiles mapping to detect if previewOrConfigFile is an
absolute path and, for that case, convert it to a file: URL (e.g., via
pathToFileURL) and then call fileURLToPath, or bypass import.meta.resolve and
directly use fileURLToPath(pathToFileURL(previewOrConfigFile)); keep using
import.meta.resolve for bare/relative specifiers and ensure the symbols
internalSetupFiles, previewOrConfigFile, import.meta.resolve, and fileURLToPath
are the points of change.
| const hasStorybookAnnotations = userSetupFiles.find((setupFile) => { | ||
| const hasStorybookSetupFileName = dirname(setupFile) === finalOptions.configDir; | ||
|
|
||
| if (!hasStorybookSetupFileName) { | ||
| return false; | ||
| } | ||
|
|
||
| // Check if the file contains setProjectAnnotations | ||
| const setupFileContent = readFileSync(setupFile, 'utf-8'); | ||
| return setupFileContent.includes('setProjectAnnotations'); | ||
| }); |
There was a problem hiding this comment.
Guard setup-file reads to avoid hard failure during config detection.
Line 50 performs an unguarded readFileSync. If a configured setup file is missing or unreadable, this path throws and can fail initialization instead of gracefully skipping detection.
💡 Proposed fix
const hasStorybookAnnotations = userSetupFiles.find((setupFile) => {
const hasStorybookSetupFileName = dirname(setupFile) === finalOptions.configDir;
if (!hasStorybookSetupFileName) {
return false;
}
// Check if the file contains setProjectAnnotations
- const setupFileContent = readFileSync(setupFile, 'utf-8');
- return setupFileContent.includes('setProjectAnnotations');
+ try {
+ const setupFileContent = readFileSync(setupFile, 'utf-8');
+ return setupFileContent.includes('setProjectAnnotations');
+ } catch {
+ return false;
+ }
});🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@code/addons/vitest/src/vitest-plugin/utils.ts` around lines 42 - 52, The
unguarded readFileSync inside the hasStorybookAnnotations computation can throw
if a setup file is missing/unreadable; wrap the readFileSync call in a try/catch
(or check existence) so that failures simply return false for that entry instead
of propagating an exception. Update the hasStorybookAnnotations logic
(referencing userSetupFiles, hasStorybookAnnotations, readFileSync,
setupFileContent, finalOptions.configDir) so any read or access error for a
setupFile is caught and treated as “no annotations” (return false) to allow
graceful config detection.
Package BenchmarksCommit: No significant changes detected, all good. 👏 |
|
Failed to publish canary version of this pull request, triggered by @valentinpalkovic. See the failed workflow run at: https://github.com/storybookjs/storybook/actions/runs/22754954776 |
1 similar comment
|
Failed to publish canary version of this pull request, triggered by @valentinpalkovic. See the failed workflow run at: https://github.com/storybookjs/storybook/actions/runs/22754954776 |
|
Failed to publish canary version of this pull request, triggered by @valentinpalkovic. See the failed workflow run at: https://github.com/storybookjs/storybook/actions/runs/22756123941 |
|
Failed to publish canary version of this pull request, triggered by @valentinpalkovic. See the failed workflow run at: https://github.com/storybookjs/storybook/actions/runs/22756222703 |
|
Failed to publish canary version of this pull request, triggered by @valentinpalkovic. See the failed workflow run at: https://github.com/storybookjs/storybook/actions/runs/22756334816 |
|
Failed to publish canary version of this pull request, triggered by @valentinpalkovic. See the failed workflow run at: https://github.com/storybookjs/storybook/actions/runs/22756820074 |
valentinpalkovic
force-pushed
the
valentin/remove-need-for-setup-file
branch
from
e73ac71 to
73af6b3
Compare
4 participants
Closes #31700
What I did
Simplified the setup experience for
@storybook/addon-vitestby removing the requirement for users to manually create and maintain avitest.setupfile. The addon now automatically provides project annotations when needed.Key Changes:
setup-file-with-project-annotations.ts) that loads project annotations from a virtual module provided by the Storybook Vite pluginrequiresProjectAnnotations()utility that intelligently detects when project annotations are needed based on:setProjectAnnotationsvitest.setupfiles during installationSETUP_FILEreferences from all Vitest config templatesBenefits:
Migration Path:
For users with existing setup files containing
setProjectAnnotations, the addon will:Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
Manual testing
Caution
This section is mandatory for all contributions. If you believe no manual test is necessary, please state so explicitly. Thanks!
Testing steps:
yarn task sandbox --template react-vite/default-ts --start-from autocd ../storybook-sandboxes/react-vite-default-tsvitest.setup.tsfile exists in.storybook/setProjectAnnotationsand verify the warning appearsAdditional testing:
Documentation
MIGRATION.MD
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal,ci:mergedorci:dailyGH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli-storybook/src/sandbox-templates.tsMake 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.Suggested label:
feature request(improves DX by removing manual setup requirement)🦋 Canary release
This pull request has been released as version
0.0.0-pr-34025-sha-73af6b3a. Try it out in a new sandbox by runningnpx storybook@0.0.0-pr-34025-sha-73af6b3a sandboxor in an existing project withnpx storybook@0.0.0-pr-34025-sha-73af6b3a upgrade.More information
0.0.0-pr-34025-sha-73af6b3avalentin/remove-need-for-setup-file73af6b3a1772789025)To request a new release of this pull request, mention the
@storybookjs/coreteam.core team members can create a new canary release here or locally with
gh workflow run --repo storybookjs/storybook publish.yml --field pr=34025Summary by CodeRabbit
New Features
Improvements
Documentation
Chores