Skip to content

Conversation

valentinpalkovic
Copy link
Contributor

@valentinpalkovic valentinpalkovic commented Jul 30, 2025

Closes #32149

What I did

What:

Explicitly tell Vite about the relationship between the module being loaded and the file its content comes from. I am doing it using the this.addWatchFile() method, which is available on the plugin context within the load and transform hooks.

Why:

When the load hook executes for a mocked module (e.g., uuid), it does this:

if (call.redirectPath) {
  // You read the file from disk...
  return readFileSync(call.redirectPath, 'utf-8'); 
}

We are returning the content of the __mocks__/uuid.ts file as a raw string. From Vite's perspective, the module uuid simply is that string content. It has no idea that this content originated from another file on the disk (mocks/uuid.ts).

As a result, when you change __mocks__/uuid.ts, Vite's watcher sees a file change, and the invalidateAffectedFiles function correctly invalidates the uuid module in the module graph. However, when Vite's dev server goes to re-serve the invalidated uuid module, it hits your load hook again. Since nothing in the hook's logic has changed, it serves the new content, but because the module's own identity (uuid) hasn't changed, Vite doesn't generate a new timestamp (?v=...). The browser, seeing a request for the exact same URL, correctly serves the old version from its cache.

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

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 canary-release-pr.yml --field pr=<PR_NUMBER>

Greptile Summary

This PR fixes a browser caching issue with Vite's development server when using manual mocks in Storybook. The change adds a single line this.addWatchFile(call.redirectPath) to Storybook's Vite mock plugin.

The problem occurs when Storybook's mock plugin reads content from __mocks__ files (e.g., __mocks__/uuid.ts) and returns it as the content for the mocked module. From Vite's perspective, the module content is just a string with no knowledge that it originated from a different file on disk. When developers modify mock files, Vite correctly invalidates the module in its module graph, but the browser continues serving cached content because Vite doesn't generate new URL timestamps (?v=...) since it's unaware of the source file dependency.

The fix uses Vite's addWatchFile() API to explicitly inform Vite about the relationship between the requested module and its source mock file. This ensures proper cache invalidation and Hot Module Replacement (HMR) behavior when mock files are modified during development.

This change integrates seamlessly with Storybook's existing mock system and follows standard Vite plugin patterns for handling dependencies between virtual modules and their source files.

PR Description Notes:

  • The PR title doesn't follow the 'Area: Summary' format specified in the style guide
  • No issue number is provided in the "Closes #" section
  • Manual testing steps are not provided despite being marked as mandatory

Confidence score: 5/5

  • This is a safe, targeted fix that addresses a specific browser caching issue with minimal risk
  • The solution follows established Vite plugin patterns and uses the appropriate API (addWatchFile)
  • No files need additional attention as the change is minimal and well-understood

Context used:

Context - PR titles must be in the format of 'Area: Summary', with both Area and Summary starting with a capital letter. (link)

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 file reviewed, no comments

Edit Code Review Bot Settings | Greptile

@valentinpalkovic valentinpalkovic changed the title test: Invalidate vite cache for manual mocks Test: Invalidate vite cache for manual mocks Jul 30, 2025
Copy link

nx-cloud bot commented Jul 30, 2025

View your CI Pipeline Execution ↗ for commit a604745

Command Status Duration Result
nx run-many -t build --parallel=3 ✅ Succeeded 1m 17s View ↗

☁️ Nx Cloud last updated this comment at 2025-07-30 20:04:47 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: 9.1 beta - Module mocking in vite does not invalidate cache
2 participants