Core: Disable component manifest by default

[yannbf]

Closes #

What I did

As title states

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

• 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

• Documentation

  • Updated componentsManifest feature docs and configuration examples to show the new default setting.

• Chores

  • Changed the default value of the componentsManifest feature flag (affects whether component manifests are generated by default).

[nx-cloud]

View your CI Pipeline Execution ↗ for commit fe28f48

Command	Status	Duration	Result
nx run-many -t compile,check,knip,test,lint,fmt...	❌ Failed	14m 4s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-04-02 14:11:02 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: 055c15b6-e9b1-4f7c-aa3f-13279fa8a211

📥 Commits

Reviewing files that changed from the base of the PR and between 7fda67e and 955fd9e.

📒 Files selected for processing (1)

• code/core/src/types/modules/core-common.ts

✅ Files skipped from review due to trivial changes (1)

• code/core/src/types/modules/core-common.ts

---

📝 Walkthrough

Walkthrough

The PR changes the default value of the componentsManifest feature flag from true to false in core presets and type docs, and updates documentation snippets to show examples that explicitly enable the feature.

Changes

Cohort / File(s)	Summary
Core preset & types code/core/src/core-server/presets/common-preset.ts, code/core/src/types/modules/core-common.ts	Toggle features.componentsManifest default from true → false in the preset and JSDoc default in the Storybook config type.
Documentation snippets docs/_snippets/main-config-features-components-manifest.md	Updated example configuration snippets (JS/TS, CSF 3 and CSF Next variants) to set features.componentsManifest: true explicitly.
API docs docs/api/main-config/main-config-features.mdx	Updated documentation text to reflect the new default componentsManifest: false.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• Core: Add changeDetection feature flag #34314: Modifies the same componentsManifest feature flag in presets and type declarations.
• Manifest: Rename experimentalComponentsManifest → componentsManifest, default to true #33974: Directly updates the componentsManifest default in core presets and related types.
• React: Change examples to stories in manifests and show correct examples and prop types #32908: Touches component-manifest-related configuration and docs, related to this feature flag change.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

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

[coderabbitai]

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/core-server/presets/common-preset.ts (1)

205-212: ⚠️ Potential issue | 🟠 Major

Add explicit migration guidance for this default flip.

Line 211 changes componentsManifest to opt-in, which disables manifest write/serve paths by default in both build and dev. That can silently break existing MCP/tooling workflows after upgrade unless users explicitly set features.componentsManifest: true. Please add a migration note/release note callout with the opt-in snippet.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@code/core/src/core-server/presets/common-preset.ts` around lines 205 - 212,
The change to the default in the exported features PresetProperty (function
named features) flips componentsManifest to opt-in and can break downstream
MCP/tooling; add a migration/release-note callout documenting the flip and
include an explicit opt-in example (tell users to set
features.componentsManifest: true in their preset/config) and where to apply it
(dev and build configs or the same preset override) so users can restore
manifest write/serve behavior; update the changelog/release notes and any
migration guide files to contain that snippet and a brief one-line explanation
referencing the features PresetProperty and componentsManifest flag.

🤖 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/core/src/core-server/presets/common-preset.ts`:
- Around line 205-212: The change to the default in the exported features
PresetProperty (function named features) flips componentsManifest to opt-in and
can break downstream MCP/tooling; add a migration/release-note callout
documenting the flip and include an explicit opt-in example (tell users to set
features.componentsManifest: true in their preset/config) and where to apply it
(dev and build configs or the same preset override) so users can restore
manifest write/serve behavior; update the changelog/release notes and any
migration guide files to contain that snippet and a brief one-line explanation
referencing the features PresetProperty and componentsManifest flag.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c344f351-b758-4132-83b9-03d11be5eb01

📥 Commits

Reviewing files that changed from the base of the PR and between 5eeadf7 and 7fda67e.

📒 Files selected for processing (4)

• code/core/src/core-server/presets/common-preset.ts
• code/core/src/types/modules/core-common.ts
• docs/_snippets/main-config-features-components-manifest.md
• docs/api/main-config/main-config-features.mdx

[shilman]

We should have some kind of prominent note in the changelog for users upgrading from 10.3.x since this is technically a breaking bugfix.