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:

["../src/**/*.stories.mdx", "../src/**/*.stories.@(js|jsx|ts|tsx)"]

The NormalizedStoriesSpecifiers passed to watchStorySpecifiers look like this:

[
  {
    titlePrefix: "",
    directory: "./src",
    files: "**/*.stories.mdx",
    importPathMatcher: /^\.[\\/](?:src(?:\/(?!\.)(?:(?:(?!(?:^|\/)\.).)*?)\/|\/|$)(?!\.)(?=.)[^/]*?\.stories\.mdx)$/,
  },
  {
    titlePrefix: "",
    directory: "./src",
    files: "**/*.stories.@(js|jsx|ts|tsx)",
    importPathMatcher: /^\.[\\/](?:src(?:\/(?!\.)(?:(?:(?!(?:^|\/)\.).)*?)\/|\/|$)(?!\.)(?=.)[^/]*?\.stories\.(js|jsx|ts|tsx))$/,
  },
];

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.

const fs = require("fs");
const originalWatch = fs.watch;
fs.watch = (...args) => {
  console.log(`fs.watch: ${args}`);
  return originalWatch(...args);
};

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.

System

Environment Info:

  System:
    OS: macOS 12.4
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 16.16.0 - /usr/local/bin/node
    Yarn: 1.22.17 - ~/.yarn/bin/yarn
    npm: 8.11.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 103.0.5060.134
    Safari: 15.5
  npmPackages:
    @storybook/addon-actions: ^6.5.7 => 6.5.7
    @storybook/addon-essentials: ^6.5.7 => 6.5.7
    @storybook/addon-interactions: ^6.5.7 => 6.5.7
    @storybook/addon-links: ^6.5.7 => 6.5.7
    @storybook/builder-webpack5: ^6.5.7 => 6.5.7
    @storybook/jest: ^0.0.10 => 0.0.10
    @storybook/manager-webpack5: ^6.5.7 => 6.5.7
    @storybook/node-logger: ^6.5.7 => 6.5.7
    @storybook/preset-create-react-app: ^4.1.2 => 4.1.2
    @storybook/react: ^6.5.7 => 6.5.7
    @storybook/testing-library: ^0.0.11 => 0.0.11