Core: Preserve Relative Indexer Import Paths

[AI-DEV-BOT]

Fixes #25554.

Summary

• Treat custom indexer importPath values as project-relative when they are not absolute paths or virtual modules.
• Keep absolute importPath handling unchanged by normalizing it relative to the Storybook working directory.
• Add regression coverage for an indexer returning ./src/A.stories.js while indexing a different source file.

Validation

• git diff --check
• node -e <path-normalization smoke check> confirmed the old logic produced ../../../../../../src/A.stories.js while the new logic preserves ./src/A.stories.js

I couldn't run the Vitest target locally because this checkout was missing Yarn's install state, and yarn install --immutable is blocked in this sandbox by temp/cache filesystem limits (ENOSPC on R:\TEMP, then EPERM writing Yarn's global cache).

Manual testing

• Not manually tested in a running Storybook instance; this change is covered by the added unit regression test and path-normalization smoke check described above.

[github-actions]

	Fails
🚫	PR is not labeled with one of: ["ci:normal","ci:merged","ci:daily","ci:docs"]

Generated by 🚫 dangerJS against 85bf6ac

[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: 8c483061-8ae2-4eaa-abfe-3397aa46b257

📥 Commits

Reviewing files that changed from the base of the PR and between d6ce689 and 85bf6ac.

📒 Files selected for processing (2)

• code/core/src/core-server/utils/StoryIndexGenerator.ts
• code/core/src/core-server/utils/__tests__/index-extraction.test.ts

---

📝 Walkthrough

Walkthrough

StoryIndexGenerator.toImportPath now detects absolute paths and converts them to working-dir-relative form before normalizing them to story import paths. A test verifies that story extraction preserves the indexer's returned importPath value when project-relative.

Changes

Path Normalization Fix

Layer / File(s)	Summary
Absolute path detection and normalization code/core/src/core-server/utils/StoryIndexGenerator.ts	Import isAbsolute from Node path module and update toImportPath to conditionally convert absolute paths to a working-dir-relative form before applying story path normalization.
Path preservation test code/core/src/core-server/utils/__tests__/index-extraction.test.ts	New test case verifies that StoryIndexGenerator.extractStories preserves the project-relative importPath value returned by the indexer in extracted story entries.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[AI-DEV-BOT]

Danger is currently failing only because the PR is missing maintainer-controlled labels:

• one category label, e.g. bug
• one CI label, e.g. ci:normal

The title format and #### Manual testing requirement have already been addressed. I tried adding bug and ci:normal, but GitHub returned 403 for my account/integration, so a maintainer will need to apply those labels to unblock the check.

[Sidnioulz]

Thanks for your PR, @AI-DEV-BOT. I am struggling to understand why it addresses the issue. In particular, #30612 was merged a while ago with a fix that ensures user importPaths are read and respected. It's our fault that the issue wasn't marked as closed, though. Sorry about that.

Here are my questions:

• Is it good, or bad, that Storybook normalises and resolves importPath values relative to the project?
• Are there use cases where preserving the path as relative causes issues in the Storybook life cycle?
• Are there use cases where forcefully converting the path relative to the project root, as is currently done, causes issues in the Storybook life cycle?
• What evidence can you provide that this PR solves the linked issue better than the code currently on next?

We'll need answers to these questions, including human judgement, in order to progress the PR. Otherwise, I'll be closing the PR. Thanks!

[AI-DEV-BOT]

Thanks for taking the time to look at this, and for pointing me to #30612. I agree that #30612 already addressed the broader issue of making custom importPath values part of the Vite story-index flow, so this PR is not intended to replace or supersede that work.

My reading is that this PR covers a narrower remaining case: when an indexer returns a non-virtual, already project-relative importPath, for example ./src/A.stories.js, StoryIndexGenerator currently passes it through relative(this.options.workingDir, path). Since path is not absolute, Node resolves it relative to the current process directory before calculating the relative path, which can turn a valid project-relative path into something like ../../../../../../src/A.stories.js.

To answer your questions:

• I think normalizing absolute importPath values relative to the project is good and should remain. That keeps the final story index consistent with the rest of Storybook.
• I think preserving an already project-relative importPath is also good, as long as we treat it as relative to the Storybook working directory/project root, not relative to the indexed source file.
• A relative importPath could cause issues if an indexer author expects it to be relative to the indexed file. In that case, the indexer should resolve it to either an absolute path or a project-relative path before returning it. It may be worth clarifying that in the docs.
• The issue with the current next behavior is specifically that it handles absolute paths correctly, but can corrupt already project-relative paths. The added regression test covers an indexer that scans ./src/A.js but returns ./src/A.stories.js as the CSF import path. On current next, the existing normalization changes that value incorrectly; with this PR, absolute paths and virtual: paths keep their existing behavior, while project-relative paths remain stable.

That said, I may have scoped this PR too broadly by linking it directly to #25554. I’m happy to retitle/reword it as a narrower follow-up to #30612 if that better reflects the intended change.

[Sidnioulz]

@AI-DEV-BOT thanks for the analysis. You pointed out two risks:

• one when the indexer returned a path relative to the project root; and we interpret it as relative to CWD
• one when the indexer returned a path relative to the indexed file (wouldn't that always be ./filename?); and we interpret it as relative to the project root

Here's where things get interesting: our current code does not guarantee that both index authors and the core server make the same interpretation. Your PR does not guarantee that either, since it's impossible to guarantee! 😄

I think we must first enforce a single interpretation, and document it well in the Indexer API doc. Then, we must decide how we want to treat relative paths depends on which interpretation we enforce:

• If we tell index authors to only send paths relative to the project root, your PR is what we want
• If we tell them to send paths relative to CWD, the code on next is what we want

Do we agree on all this? If you reached the same conclusion as me, here's how I think you could help:

• Decide on how we want index authors to compute relative paths
• Check whether the Indexer API documentation aligns with that decision
• Adjust the code accordingly based on which bucket we fall in