Graph Creation: @nx/storybook/plugin:createNodes is very slow in large projects

[comp615]

Current Behavior

Problem
@nx/storybook/plugin is very slow in monorepos with numerous storybook projects.

As shown below @nx/storybook/plugin is taking over 27s in our repo to generate the graph:

nx reset && NX_PERF_LOGGING=true NX_DAEMON=false NX_VERBOSE_LOGGING=true nx graph
...
Time for '@nx/storybook/plugin:createNodes' 27310.746499999997

This is a reopening of #31276. The problem is that now we use a shared storybook config, so every storybook is just:

export { default } from '@squareup/storybook-config/main';

and the early exit from the plugin that we put back in no longer helps

Expected Behavior

We now have a pnpm patch in to skip framework detection:

Time for '@nx/storybook/plugin:createDependencies' 30.96295800000007

I don't think this is viable as a PR though, but as mentioned in the previous issue there's a handful of solutions that could be considered:

• Remove bespoke build behavior alleviating need to detect frameworks
• Add an escape hatch to the nx.json plugin config to skip framework detection and give it statically (always / never angular)
• Somehow coordinate the angular detection with storybook detection instead of fully resolving the config (i.e. angular + storybook on a project implies the intersection)
• Create a per node override mechanism (i.e. project.json could specify plugin argument overrides)...more granular than the second option
• Generalize the problem and create a more complex but flexible heuristic (i.e. manually traverse imports doing AST until a key string is found)

GitHub Repo

No response

Steps to Reproduce

1. Make a repo with with lots of storybook projects and configs
2. run the given command to see graph generation

Nx Report

NX   Report complete - copy this into the issue template

Node           : 20.19.1
OS             : darwin-arm64
Native Target  : aarch64-macos
pnpm           : 10.12.1

nx                     : 21.3.6
@nx/js                 : 21.1.2
@nx/jest               : 21.3.6
@nx/eslint             : 21.3.6
@nx/workspace          : 21.3.6
@nx/cypress            : 21.3.6
@nx/devkit             : 21.3.6
@nx/eslint-plugin      : 21.3.6
@nx/module-federation  : 21.3.6
@nx/plugin             : 21.3.6
@nx/react              : 21.3.6
@nx/storybook          : 21.3.6
@nx/vite               : 21.3.6
@nx/web                : 21.3.6
typescript             : 5.5.4

---------------------------------------
Nx key licensed packages
Licensed to Block Inc..

@nx/powerpack-s3-cache  : 3.0.0

---------------------------------------
Registered Plugins:
@nx/vite/plugin
@squareup/service-dashboard-web-runtime/nx-plugin
@nx/storybook/plugin
@squareup/nx-lint-plugin
@squareup/nx-stats-plugin
@squareup/service-i18n/nx-plugin
@squareup/infra-e2e-playwright/nx-plugin
---------------------------------------
Community plugins:
@squareup/infra-e2e-playwright : 0.0.0
@squareup/service-i18n         : 0.100.1
---------------------------------------
Local workspace plugins:
@squareup/infra-e2e-playwright
@squareup/service-i18n
@squareup/migrate
---------------------------------------
Cache Usage: 0.00 B / 92.64 GB
---------------------------------------

Failure Logs

Package Manager Version

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

This was previously discussed in #31276 where we brought back the simpler detection escape hatch. However, that's no longer sufficient and it might be time to more directly address the underlying problems.

FWIW, this seems like it'd be a more universal problem with config parsing, so it might be a more ideological thing to discuss w.r.t. scaling.