Core: Fetch static open-service snapshots relative to the document - #35945
Conversation
`createBrowserStaticLoader` requested `/services/<path>`, resolved against the origin root rather than the deployed directory. A Storybook served below the root - a GitHub Pages project site, a docs site mounted under a path - therefore fetched its snapshots from a location that belongs to a different site, and every open-service static load 404'd. Every other build artifact is already document-relative: `STORY_INDEX_PATH` is `./index.json` in both the preview and the manager. This aligns the services prefix with that, and fixes the same defect in the preview navigator's index fetch.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 17 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 60 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
Comment |
Package BenchmarksCommit: The following packages have significant changes to their size or dependencies:
|
| Before | After | Difference | |
|---|---|---|---|
| Dependency count | 20 | 20 | 0 |
| Self size | 23.13 MB | 23.11 MB | 🎉 -20 KB 🎉 |
| Dependency size | 11.49 MB | 11.49 MB | 0 B |
| Bundle Size Analyzer | Link | Link |
…-services-subpath-fetch Core: Fetch static open-service snapshots relative to the document (cherry picked from commit a6714df)
What I did
Static open-service snapshots were fetched from
/services/<path>, an origin-absolute URL.A Storybook served below the origin root - a GitHub Pages project site, a docs site mounted under a path - therefore asked for its snapshots at a location belonging to a different site, and every static open-service load 404'd.
Every other build artifact is already document-relative.
STORY_INDEX_PATHis./index.json, in both the preview and the manager. This aligns the services prefix with that.The same defect in the preview navigator's index fetch is fixed alongside it, since it is the identical one-line mistake.
The failure, captured
A real
storybook buildserved under/storybook/, before the fix. The Open Service static-load story renders its query results:nullnull"static-load:alpha""static-load:beta"Network for that page, before:
After:
The user-facing consequence is wider than the demo story: with
experimentalDocgenServeron,core/story-docsis what fills the Code panel and autodocs source blocks, so on a sub-path deploy those went blank.@storybook/angular-viteturns that flag on from its own preset, so the regression shipped there by default.The change
Relative resolution is what makes the manager and the preview agree:
index.htmlandiframe.htmlare siblings in the build output, so./services/…resolves to the same place from either document. That is the property the old comment claimed the absolute path was needed for.Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
code/core/src/shared/open-service/static-fetch.test.tsgains a case asserting the request resolves under the deployment directory from both the manager document URL and the preview iframe document URL. The existing cases that pinned the absolute URL are updated.Not covered by an e2e: the existing static-build specs serve Storybook at the origin root, so none of them can observe this. Adding a sub-path variant means teaching the e2e harness to serve under a prefix, which is more than this fix should carry.
Manual testing
Requires a build made with the docgen server on, since that is what populates
services/.cd code && STORYBOOK_EXPERIMENTAL_DOCGEN_SERVER=true yarn storybook:ui:buildcd /tmp/sb-site && python3 -m http.server 8101(Use
python3 -m http.server, notnpx serve- the latter strips.htmlby default and 301siframe.html, which breaks the preview for unrelated reasons.)http://localhost:8101/storybook/?path=/story/core-shared-open-service-sync-test-static-load--static-load-syncEntry alphaandEntry betashould read"static-load:alpha"and"static-load:beta". Onnextthey readnull.http://localhost:8101/storybook/?path=/story/addons-docs-codepanel--defaultand select the Code tab. The snippet should render. Onnextthe panel stays empty.services/…request should be under/storybook/services/…and return 200.Documentation
MIGRATION.MD
No documentation change: this restores the behavior the docs already describe.
docs/sharing/publish-storybook.mdxlists GitHub Pages as a supported target.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.tsDeclare whether manual QA will be needed for this PR during the next release, through
qa:neededorqa:skipMake 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.