Nx graph ends up in a deadlock with a package base mono + @nx/vite/plugin + a local vite plugin library

Current Behavior

The Nx graph is in a half broken state, and so it won't let me build a library that dosn't depends on a broken inference library. The library are in a broken state because a nx crystal plugin is trying to import their configs that depends on a workspace package that needs building (more info in the reproduction readme)

Expected Behavior

Either nx lets me build a library that is not affected by a broken inference project, or I have the tools to easily create my own plugin from building blocs from Nx's plugins, see https://github.com/nrwl/nx/discussions/22099#discussioncomment-8801922

GitHub Repo

https://github.com/beaussan/nx-repro-crystal-loop

Steps to Reproduce

Here is defined in the repo above.

If you want to make it yourself:

Create a library that is build with tsc (so it's minimal)
Expose a vite plugin from that library
Create another library
Import the plugin you create into the vite config
Nx reset + fresh workspace
Things should break

Nx Report

NX   Report complete - copy this into the issue template

Node           : 20.11.1
OS             : darwin-arm64
Native Target  : aarch64-macos
yarn           : 4.3.1

nx             : 19.5.4
@nx/js         : 19.5.4
@nx/linter     : 19.5.4
@nx/eslint     : 19.5.4
@nx/workspace  : 19.5.4
@nx/cypress    : 19.5.4
@nx/devkit     : 19.5.4
@nx/react      : 19.5.4
@nx/storybook  : 19.5.4
@nrwl/tao      : 19.5.4
@nx/vite       : 19.5.4
@nx/web        : 19.5.4
typescript     : 5.5.4
---------------------------------------
Registered Plugins:
@nx/vite/plugin

Failure Logs

No response

Package Manager Version

yarn@4.3.1

Operating System

[X] macOS
[X] Linux
[ ] Windows
[ ] Other (Please specify)

Additional Information

No response

Hey @beaussan, I have a workaround for this issue here: https://github.com/jaysoo/issue27244

The global.NX_GRAPH_CREATION variable can be used to guard against code paths that should only happen at build time. This solves the issue of the library not being built first.

There isn't a great way to resolve this any other way, since you don't want to have builds happen before the graph is created. Perhaps we need some documentation in Extending Nx for these kinds of use cases.

Hey @jaysoo , that's good to know there is a global that is set when the graph is being setup!

However, this would only work for very simple use cases, here is what my shared vite plugin in my enterprise monorepo does:

sets the output dist folder => without it, nx won't have the right cache output
sets the server for our dev mode => without it, nx won't infer and create a dev + serve target

And we have the same with our storybook config, where we have a shared config that define what kind of storybook runner is it, something Nx needs to create storybook targets.

One solution I would like to have is, like generators are exported without the same expected stability as the devkit, expose some functions within the createNodes for such plugins as the buildTarget, serveTarget, previewTarget serveStaticTarget and testTarget from https://github.com/nrwl/nx/blob/master/packages/vite/src/plugins/plugin.ts or the buildTarget, serveTarget, testTarget and serveStaticTarget of the https://github.com/nrwl/nx/blob/master/packages/storybook/src/plugins/plugin.ts storybook plugin to allow advanced users to create their own nx crystal plugin, that doesn't look at the code config (aka vite.config.ts) and at the same time have the metadata improvement that is not well documented (metadata with descriptions, help, etc).

Because, if you are already a power user to create shared configuration for your tools, you know the output they should have, having the tradeoff of "build your own crystal plugins with some building blocks we provide" is not so far fetch.

nrwl / nx