You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR: I don't think we should be passing relative paths to watchpack since it's effectively causing 2x as many calls to fs.watch. This isn't a bug per-se, but it's probably not great for performance, and it makes encountering another bug with watchpack on osx more common.
And ultimately we call wp.watch({ directories: ["./src"] }).
Watchpack internally re-uses watchers, with caching keyed off the path being watched. Webpack also internally uses watchpack, but it uses absolute paths instead of relative ones, so the watchers created by storybook can't be shared with those created by webpack.
We can demonstrate this by creating a test project with storyStoreV7 enabled, adding this to the top of node_modules/.bin/start-storybook to log fs.watch calls, and then calling yarn run start-storybook.
You should see two fs.watch calls for all the directories being watched, one relative created by storyook and one absolute created later by webpack after the initial compilation completes. If you change /node_modules/@storybook/core-server/dist/cjs/utils/watch-story-specifiers.js to use absolute paths instead by wrapping ns.directory in _path.default.resolve you'll see half as many.
This is triggering another bug where watchpack can potentially hang for a long time after 2000+ watchers are created on osx. Since all directories are being watched twice, this threshold gets hit a lot sooner.
Describe the bug
TL;DR: I don't think we should be passing relative paths to watchpack since it's effectively causing 2x as many calls to
fs.watch
. This isn't a bug per-se, but it's probably not great for performance, and it makes encountering another bug with watchpack on osx more common.When running with
storyStoreV7
enabled we create a watcher via watchpack in watch-story-specifiers.ts. For a configuration like this:The
NormalizedStoriesSpecifier
s passed towatchStorySpecifiers
look like this:And ultimately we call
wp.watch({ directories: ["./src"] })
.Watchpack internally re-uses watchers, with caching keyed off the path being watched. Webpack also internally uses watchpack, but it uses absolute paths instead of relative ones, so the watchers created by storybook can't be shared with those created by webpack.
We can demonstrate this by creating a test project with
storyStoreV7
enabled, adding this to the top ofnode_modules/.bin/start-storybook
to logfs.watch
calls, and then callingyarn run start-storybook
.You should see two
fs.watch
calls for all the directories being watched, one relative created by storyook and one absolute created later by webpack after the initial compilation completes. If you change/node_modules/@storybook/core-server/dist/cjs/utils/watch-story-specifiers.js
to use absolute paths instead by wrappingns.directory
in_path.default.resolve
you'll see half as many.This is triggering another bug where watchpack can potentially hang for a long time after 2000+ watchers are created on osx. Since all directories are being watched twice, this threshold gets hit a lot sooner.
System
The text was updated successfully, but these errors were encountered: