NX project graph calculation hanging indefinitely

[electrocnic]

Current Behavior

When I created a nx monorepo following the documentation using the single version strategy (where the documentation claims that a package.json is only needed at the workspace root but not for the individual apps), everything worked fine so far, could build the first app which was automatically added by the generator.

I already had issues in the beginning tho, that some nx commands (some plugins perhaps, I used a vite typescript react app with eslint and prettier) failed because they wanted a package.json at the root of the project (meaning the app, not the workspace), so I searched a while online and just added a stupid simple package.json to the app with only the name, the version and nothing else. It worked again, nx built the project graph and built the app and served it.

After some days I wanted to add a second app to my monorepo. Directly with the @nx/react generator in the VSCode extension to generate my app.

Settings were:

directory: apps/app2
bundler: vite
linter: eslint
name: myAppName
unitTestRunner: vitest
compiler: babel
e2eTestRunner: none
strict: true
style: tailwind

Once I generated this app, everything began to hang in the VSCode nx console. It tried to refresh the workspace indefinitely. I started using terminal console commands manually like npx nx reset, npx nx run build:app2 and waited and waited and waited. Deleted node_modules completely and ran npm i from scratch, installed latest node LTS 22 version on the Windows host machine, restarted the computer, and so on. Deleted the second app again from the repo and it worked again and built the app. Re-generated the second app, freeze. Deleted app2 again, worked again, Re-generated, freeze again.

Always with Calculating the project graph on the Nx Daemon is taking longer than expected. Re-run with NX_DAEMON=false to see more details. then NX_DAEMON=false npx nx run build:app2 --> hangs at Creating project graph dependencies with 6 plugins. sometimes just Failed to process project graph. Run "nx reset" to fix this.

Also, any nx command failed, not just for app2, but also for app1.

When I finally figured, the only difference between app1 and app2 was, that the generator did not add a package.json to the freshly created app2, I copied the slim one from app1, renamed the name field for app2 and voila, it worked again.

Content of the package.json on app-level:

{
  "name": "@appX",
  "version": "0.0.0",
  "private": true,
  "dependencies": {}
}

Expected Behavior

• nx commands should not hang up without error messages if package.json files are missing.
• The nx documentation should not falsely claim that, for single-version monorepos, a package.json is not needed per app, but only one per workspace root, which apparently is wrong (at least in my configured setup, where I wanted to have type: module in my workspace root, and with the tools that I used).
• the @nx/react generator should add a package.json to the generated app
• or, if all of this is a wrong configuration on my side, the nx documentation should clearly show how to configure the monorepo with type:module (for ESM type projects (not talking about nx plugins, but about my project code)) without package.jsons in each app folder, because it does not work with this setup, as some plugins will complain about the missing package.json, being it typescript, eslint, vite or something else.

GitHub Repo

No response

Steps to Reproduce

1. in a fresh location npm i -D @nx/react/latest (selecting vite, typescript, eslint, prettier)
2. add "type": "module" to workspace root package.json
3. tsconfig.base.json: "moduleResolution": "bundler", "target": "es2022", "lib": ["es2023", "DOM", "DOM.Iterable"] this should be the key changes where trying to build the app produce some "package.json missing" errors.

Nx Report

Node           : 22.13.0
OS             : win32-x64
Native Target  : x86_64-windows
npm            : 11.0.0

nx                     : 20.3.1
@nx/js                 : 20.3.1
@nx/eslint             : 20.3.1
@nx/workspace          : 20.3.1
@nx/devkit             : 20.3.1
@nx/eslint-plugin      : 20.3.1
@nx/module-federation  : 20.3.1
@nx/react              : 20.3.1
@nx/vite               : 20.3.1
@nx/web                : 20.3.1
typescript             : 5.7.3
---------------------------------------
Registered Plugins:
@nx/vite/plugin
@nx/eslint/plugin
@nx/js/typescript

Failure Logs

Package Manager Version

No response

Operating System

• [ ] macOS
• [ ] Linux
• [x] Windows
• [ ] Other (Please specify)

Additional Information

No response

[thengstermanndev]

Currently facing the same issue. In my case i'm forced to shutdown my computer since this is blowing up my RAM.

I'm using macOS

Edit: In my case removing Nx Console extension from VSCode resolved the issue.

[MajorTom327]

Got something similar. But in my case, no extension. Running directly the command from the console. Only one project. The command nx serve app just block on the generating graph thing. But even the nx show project app and the nx report are in the same issue. Was trying to build a react 19 + vite + react router 7 app in ESM. No log, no feedback is pretty hard to get any informations on what's going on and find exactly where could be the issue. (Nx side? Vite side? Configuration Side?)

[canibanoglu]

I'm in the same boat, using MacOS, latest version of nx.

What I found out is that if I try to install a package (@llama/chat-ui in this case), things just start to blow up. First I start getting issues from typescript which lead me to make the following changes:

• add "type": "module" to my nx ui library's package.json, not the root one. I'm assuming this fixes the error I get from import { xxx } from "@llama/chat-ui"
• switch moduleResolution from node to bundler.

After those simply gets stuck at graph generation. There's nothing in .nx/workspace-data/d/daemon.log, it's just stuck. Setting NX_DAEMON=false has absolutely no effect.

More information: This is only happening if I try to import into the ui library components. If I'm doing all of the work within the app project, everything works fine.

[curious-33]

I got the same issue, the process of calculating the project graph is hanging there. I imported an app from another repo and then got this issue:

At first attempt(I mean after I clean the node_modules and clear nx caches), there is no hanging issue. But when I tried to run my local env 2nd time, I got the issue.

The versions of my nx packages:

• "@nrwl/linter": "^19.8.4",
• "@nrwl/vite": "^19.8.4",
• "@nx/eslint": "20.3.1",
• "@nx/eslint-plugin": "20.3.1",
• "@nx/jest": "20.3.1",
• "@nx/js": "20.3.1",
• "@nx/react": "20.3.1",
• "@nx/vite": "20.3.1",
• "@nx/web": "20.3.1",
• "@nx/workspace": "20.3.1",
• "nx": "20.3.1",

[mamun2519]

Currently, I am facing this issue while setting up a new project. I have another existing project using Nx, where everything is working perfectly. https://i.ibb.co.com/gZNkgr3/Screenshot-from-2025-01-20-09-32-25.png

[studix]

Same issue here. The versions of nx in my root package.json:

"@ngrx/schematics": "19.0.0", "@ngrx/store-devtools": "19.0.0", "@nx/esbuild": "20.3.2", "@nx/eslint": "20.3.1", "@nx/eslint-plugin": "20.3.1", "@nx/jest": "20.3.1", "@nx/js": "20.3.2", "@nx/node": "^20.3.2", "@nx/storybook": "20.3.1", "@nx/web": "20.3.1", "@nx/workspace": "20.3.1", "nx": "20.3.1",

Does anybody know a workaround?

[mmlngl]

Same, in my nx + vite + rr7 app.

Although it seems to be the tailwind config that breaks it:

• Without tailwind, works
• Add tailwind (nx g @nx/react:setup-tailwind --project=<your app here>) and it breaks

[mmlngl]

Same, in my nx + vite + rr7 app.

Although it seems to be the tailwind config that breaks it:

• Without tailwind, works
• Add tailwind (nx g @nx/react:setup-tailwind --project=<your app here>) and it breaks

More investigation. Delete the postcss.config file and it works again. Vite doesn't need it.

[fridezlucas]

Isn't it related to [email protected] ? I created a fresh nx workspace with tailwind v4 and this error occured. I switch to tailwind 3 and workspace is now working !

[Lonli-Lokli]

same for me, solved by adding two package,json to both apps (react/next) also facing Projects should use relative imports to import from other files within the same project. while Im importing library code from app code

[kustomq]

We need [email protected] support, currently even the guide https://nx.dev/recipes/react/using-tailwind-css-in-react is outdated.

[roldengarm]

I'm having the same problem after upgrading to NX20 / Angular, when trying to run the migrations with

npx nx migrate --run-migrations It's doing an npm install first, which hangs at Creating project graph dependencies with 6 plugins

In my case, it was caused by the nx-dotnet plugin. It has a "prepare" script to run dotnet restore. Once I remove that, it works...

I did have to add an almost empty package.json to each project as OP also suggested.

[SoftwareDesign-Solution]

We need [email protected] support, currently even the guide https://nx.dev/recipes/react/using-tailwind-css-in-react is outdated.

If you are using tailwindcss 4.0.0, then change the styles.css as described in the instructions https://tailwindcss.com/docs/upgrade-guide#removed-tailwind-directives, then the monorepo will work again

[electrocnic]

We need [email protected] support, currently even the guide https://nx.dev/recipes/react/using-tailwind-css-in-react is outdated.

If you are using tailwindcss 4.0.0, then change the styles.css as described in the instructions https://tailwindcss.com/docs/upgrade-guide#removed-tailwind-directives, then the monorepo will work again

Can confirm that I got it running with tailwind 4.0.0.

@kustomq Steps that I had to do:

1. Included in every app in the monorepo:

import tailwindcss from '@tailwindcss/vite'
defineConfig(...
  plugins: [tailwindcss(), ...]
}

as stated in https://tailwindcss.com/docs/installation/using-vite this gave me an error about ESM vs CJS for this tailwindcss-vite plugin.

2. Therefore added "type": "module", to the app-local package.json too.
3. Renamed my main.scss to main.css as I figured I no longer want to use sass with its compatibility issues with tailwind and its deprecation warnings. Anyways, no real need for sass with tailwind after all. See https://tailwindcss.com/docs/compatibility#sass-less-and-stylus
4. Add @import "tailwindcss"; to my apps' main.css (replacing the old 3 tailwind import lines as instructed in the documentation).
5. Migrated existing themes, variables, animation keyframes from my tailwind.config.js to the main.css where I import the tailwindcss. See https://tailwindcss.com/docs/theme (Note that this step took some effort as the syntax is very different from javascript, and the nesting too).
6. Deleted tailwind.config.js and postcss.config.js
7. npm remove autoprefixer postcss @tailwindcss/postcss sass
8. npm i -D @tailwindcss/vite tailwindcss@latest
9. npx nx reset
10. npx nx sync

Hope I did not forget anything, it should work.

[electrocnic]

After some while, my observation is the following:

The originally stated freezes seem to always happen for any kind of misconfiguration across the whole workspace. If any project.json, package.json, tsconfig.json or even vite.config.ts files are producing internal errors, which might or might not be visible in the VS-Code "PROBLEMS" tab, this would lead to such a freeze in my case.

Once I fix such sensitive problems, then run nx reset, nx sync, npm i freshly (sometimes even from scratch by deleting the whole node_modules folder and running npm ci, it works again.

[richardfeliciano]

I tried everything above, the only thing I got was the error below:

`⠧ Creating project graph nodes with 2 plugins

• @nx/remix/plugin
• @nx/eslint/plugin [Nx Vite TsPaths] Found tsconfig at /Users/ricks/Developer/project-name/tsconfig.base.json

[Nx Vite TsPaths] first parsed tsconfig: { resultType: 'success', configFileAbsolutePath: '/Users/ricks/Developer/project-name/tsconfig.base.json', baseUrl: undefined, absoluteBaseUrl: '/Users/ricks/Developer/project-name', paths: {}, addMatchAll: false }

[Nx Vite TsPaths] Found tsconfig at /Users/ricks/Developer/project-name/tsconfig.base.json

[Nx Vite TsPaths] fallback parsed tsconfig: { resultType: 'success', configFileAbsolutePath: '/Users/ricks/Developer/project-name/tsconfig.base.json', baseUrl: undefined, absoluteBaseUrl: '/Users/ricks/Developer/project-name', paths: {}, addMatchAll: false } fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]: github.com/evanw/esbuild/internal/helpers.(*ThreadSafeWaitGroup).Wait(...) github.com/evanw/esbuild/internal/helpers/waitgroup.go:36 main.runService.func2() github.com/evanw/esbuild/cmd/esbuild/service.go:114 +0x59 main.runService(0x1) github.com/evanw/esbuild/cmd/esbuild/service.go:160 +0x4ed main.main() github.com/evanw/esbuild/cmd/esbuild/main.go:241 +0xa29

goroutine 6 [chan receive]: main.runService.func1() github.com/evanw/esbuild/cmd/esbuild/service.go:98 +0x4a created by main.runService github.com/evanw/esbuild/cmd/esbuild/service.go:97 +0x1e5

goroutine 7 [chan receive]: main.(*serviceType).sendRequest(0xc000184090, {0x154fde0, 0xc000400180}) github.com/evanw/esbuild/cmd/esbuild/service.go:192 +0xfa main.runService.func3() github.com/evanw/esbuild/cmd/esbuild/service.go:125 +0x39 created by main.runService github.com/evanw/esbuild/cmd/esbuild/service.go:122 +0x31c

goroutine 36 [chan receive]: github.com/evanw/esbuild/internal/bundler.(*scanner).scanAllDependencies(0xc000609200) github.com/evanw/esbuild/internal/bundler/bundler.go:2024 +0x239 github.com/evanw/esbuild/internal/bundler.ScanBundle(, {, _, _, _, _, }, {, }, 0xc00007e2a0, ...) github.com/evanw/esbuild/internal/bundler/bundler.go:1371 +0xb36 github.com/evanw/esbuild/pkg/api.rebuildImpl({0xc00007e2a0, {0x0, 0x0, 0x0}, {0x0, 0x0, 0x0}, {0x0, 0x1, 0x2, ...}, ...}, ...) github.com/evanw/esbuild/pkg/api/api_impl.go:1458 +0x2e5 github.com/evanw/esbuild/pkg/api.(*internalContext).rebuild() github.com/evanw/esbuild/pkg/api/api_impl.go:977 +0x2a5 github.com/evanw/esbuild/pkg/api.(*internalContext).Rebuild(...) github.com/evanw/esbuild/pkg/api/api_impl.go:1038 github.com/evanw/esbuild/pkg/api.Build({0x2, 0x4, 0x0, 0xc000184540, 0x1, {0x0, 0x0}, 0x0, 0x0, {0xc000010348, ...}, ...}) github.com/evanw/esbuild/pkg/api/api.go:385 +0xb6 main.(*serviceType).handleBuildRequest(0xc000184090, 0x1?, 0xc0003cd7a0?) github.com/evanw/esbuild/cmd/esbuild/service.go:763 +0xe58 main.(*serviceType).handleIncomingPacket.func2() github.com/evanw/esbuild/cmd/esbuild/service.go:235 +0x68 created by main.(*serviceType).handleIncomingPacket github.com/evanw/esbuild/cmd/esbuild/service.go:233 +0x1c5

goroutine 69 [chan receive]: main.(*serviceType).sendRequest(0xc000184090, {0x154fde0, 0xc000204420}) github.com/evanw/esbuild/cmd/esbuild/service.go:192 +0xfa main.(*serviceType).convertPlugins.func2.3({{0xc0002f2730, 0xe}, {0xc0003c2190, 0x41}, {0x15c2b12, 0x4}, {0xc0003c2190, 0x32}, 0x2, {0x0, ...}, ...}) github.com/evanw/esbuild/cmd/esbuild/service.go:985 +0x933 github.com/evanw/esbuild/pkg/api.(*pluginImpl).onResolve.func1({{0xc0002f2730, 0xe}, {0xc0003c2190, 0x32}, {0x0, 0x0}, {{0xc0003c2190, 0x41}, {0x15c2b12, 0x4}, ...}, ...}) github.com/evanw/esbuild/pkg/api/api_impl.go:1894 +0x215 github.com/evanw/esbuild/internal/bundler.RunOnResolvePlugins({_, _, _}, _, {0xc000388230, 0xc0003e2180, 0xc0003e21c8, 0xc0003b8060, 0x4, 0xc000184660}, ...) github.com/evanw/esbuild/internal/bundler/bundler.go:939 +0x8b5 github.com/evanw/esbuild/internal/bundler.parseFile({{0x16bb170, 0xc0003b8140}, {0xc000388230, 0xc0003e2180, 0xc0003e21c8, 0xc0003b8060, 0x4, 0xc000184660}, 0xc000608d80, 0xc00007e2a0, ...}) github.com/evanw/esbuild/internal/bundler/bundler.go:500 +0x31d5 ⠦ Creating project graph dependencies with 8 plugins`

[Vondry]

We need [email protected] support, currently even the guide https://nx.dev/recipes/react/using-tailwind-css-in-react is outdated.

If you are using tailwindcss 4.0.0, then change the styles.css as described in the instructions https://tailwindcss.com/docs/upgrade-guide#removed-tailwind-directives, then the monorepo will work again

Can confirm that I got it running with tailwind 4.0.0.

@kustomq Steps that I had to do:

1. Included in every app in the monorepo:

import tailwindcss from '@tailwindcss/vite' defineConfig(... plugins: [tailwindcss(), ...] } as stated in https://tailwindcss.com/docs/installation/using-vite this gave me an error about ESM vs CJS for this tailwindcss-vite plugin.

2. Therefore added "type": "module", to the app-local package.json too.
3. Renamed my main.scss to main.css as I figured I no longer want to use sass with its compatibility issues with tailwind and its deprecation warnings. Anyways, no real need for sass with tailwind after all. See https://tailwindcss.com/docs/compatibility#sass-less-and-stylus
4. Add @import "tailwindcss"; to my apps' main.css (replacing the old 3 tailwind import lines as instructed in the documentation).
5. Migrated existing themes, variables, animation keyframes from my tailwind.config.js to the main.css where I import the tailwindcss. See https://tailwindcss.com/docs/theme (Note that this step took some effort as the syntax is very different from javascript, and the nesting too).
6. Deleted tailwind.config.js and postcss.config.js
7. npm remove autoprefixer postcss @tailwindcss/postcss sass
8. npm i -D @tailwindcss/vite tailwindcss@latest
9. npx nx reset
10. npx nx sync

Hope I did not forget anything, it should work.

There is actually much easier way how to add Tailwind 4 support for shared libs - using @source directive

• Let's say I have my project app under apps/my-main-fe-app and the i have react lib under libs/ui, then i just needed to add @source "../../../../../libs/ui/src/"; (relative path depends on your project) to my main tailwind.css configuration file under apps/my-main-fe-app .

Although would be nice if this could be somehow manager using plugin...

[electrocnic]

There is actually much easier way how to add Tailwind 4 support for shared libs - using @source directive

Thanks for the hint to the sources directive, much appreciated, this likely just nudged me into an undetected bug in my current nx monorepo which I will likely need to resolve with this directive.

• Let's say I have my project app under apps/my-main-fe-app and the i have react lib under libs/ui, then i just needed to add @source "../../../../../libs/ui/src/"; (relative path depends on your project) to my main tailwind.css configuration file under apps/my-main-fe-app .

However, let me add my two cents here:

just needed to add @source "../../../../../libs/ui/src/";

screems like a bad architecture to me.

It is likely a very bad setup in your nx monorepo, because having to include another lib in your current lib with such a big relative path pointing so many layers up, just to go back down the hierarchy, cannot be good. Likely you will circumvent the nx module encapsulation linting rules, bypassing them because they won't look for tailwind source directives (I just assume that). Next, you will likely introduce some sort of circular dependency (even if not technically problematic in this case, as the source directive will not interfere with ts or js imports, but still), so that the ultimate consequence is, that your libs do not follow a unidirectional dependency flow anymore (which is just strongly recommended to maintain, not a strict necessity, but I still want to mention this for anybody else reading your statements).

Also, this statement is wrong:

There is actually much easier way how to add Tailwind 4 support for shared libs

The addition of the source directive does not replace in any means the 10 steps that I listed in my previous post. You definitely need to add those things to your workspace somewhere or tailwind will not work. It just means, that if you put tailwind in one common reusable assets lib, like I do, and want to apply the tailwind import to any other lib in the workspace, there might be the need to let tailwind know that it should scan for other sources too beyond the lib folder in which it is imported, namely the other workspace libs. I still have to look into this, I can only say: As long as I used non-buildable libs, this was not necessary. As soon as I switched to buildable libs, my css was not applied correctly anymore. This might very likely be the reason.

[adiffmike]

After some while, my observation is the following:

The originally stated freezes seem to always happen for any kind of misconfiguration across the whole workspace. If any project.json, package.json, tsconfig.json or even vite.config.ts files are producing internal errors, which might or might not be visible in the VS-Code "PROBLEMS" tab, this would lead to such a freeze in my case.

Once I fix such sensitive problems, then run nx reset, nx sync, npm i freshly (sometimes even from scratch by deleting the whole node_modules folder and running npm ci, it works again.

Just ran into this issue when upgrading to tailwind 4.

The above solution about addressing errors seemed to work for me. I had some eslint nx-dependency-check issues, which I fixed then everything worked again. YMMV

[Vondry]

electrocnic you are correct that using @source is only good when you do not have buildable shared libs.

If i am not mistaken then @source directive in Tailwind v4 effectively replacing content configuration in Tailwind V3.

How it works for Tailwind V3 in NX is described here:

In the above, you are invoking the createGlobPatternsForDependencies utility function with the __dirname of the project root. The utility function will identify the project app1 and obtain its dependencies from the project graph. It will then create the glob patterns for each dependency and return them as an array. If app1 were to have lib1 and lib2 as dependencies, the utility function will return the following glob patterns.

So basically we need to have similar functionality for the new @source directive in our css files so that we do not need to write the path manually as i did. That sounds correct?

• We might actually use @config directive in V4 to load JS config from V3...

And you are of course correct, this approach works only for non-buildable libs. If i would need to have buildable lib, i guess that i would need to configure tailwind in that lib as well (figuring out how to share css configuration etc...) => that would be also interesting for me.

[electrocnic]

i guess that i would need to configure tailwind in that lib as well (figuring out how to share css configuration etc...) => that would be also interesting for me.

I investigated into a few approaches today, and settled for your initial response of using the @source directive with this long and ugly relative path 😅:

Project setup:

libs/frontend/shared/ui/assets/
  src/assets/css/main.css:
    /*
      @import 'tailwindcss';
      @source '../../../../../../../../libs/**/*.{ts,tsx,html}';
      @source '../../../../../../../../apps/**/*.{ts,tsx,html}';
    */
  vite.config.ts:
    /*
      import { createBaseViteConfig } from '../../../../../vite.library.base.config'
        export default defineConfig(() =>
          mergeConfig(createBaseViteConfig(__dirname, ...)
    */
vite.base.config:
/*
export function createBaseViteConfig() {
  return defineConfig({
    plugins: [tailwindcss(), ...]
*/

I apologize for my initial harsh response about the relative path. I did not fully understand how tailwind works at that time and thanks to your documentation links and explanations, I do now understand how tailwind works and why this is a plausible and valid solution.

Explanation for my above code: For every buildable lib that exists in my monorepo, each will be based on the workspace-global vite.base.config which adds the tailwind plugin. Might be, that not every lib would need that, but at least the apps will need this plugin and not just the assets plugin alone. I tested around a little bit and this was a working solution.

I only import this main.css once in my main.tsx of the app, and in no other lib throughout the monorepo. I tested to add tailwind classes in different libs, and it worked.

[Tiramisupxl]

We need [email protected] support, currently even the guide https://nx.dev/recipes/react/using-tailwind-css-in-react is outdated.我们需要 [email protected] 支持，目前甚至指南https://nx.dev/recipes/react/using-tailwind-css-in-react也已经过时了。

If you are using tailwindcss 4.0.0, then change the styles.css as described in the instructions https://tailwindcss.com/docs/upgrade-guide#removed-tailwind-directives, then the monorepo will work again如果您使用的是 tailwindcss 4.0.0，请按照说明https://tailwindcss.com/docs/upgrade-guide#removed-tailwind-directives中所述更改 style.css，然后 monorepo 将再次工作

Can confirm that I got it running with tailwind 4.0.0.可以确认我已经使用 tailwind 4.0.0 运行它。

@kustomq Steps that I had to do:我必须执行的步骤：

1. Included in every app in the monorepo:包含在 monorepo 中的每个应用程序中：

import tailwindcss from '@tailwindcss/vite' defineConfig(... plugins: [tailwindcss(), ...] } as stated in https://tailwindcss.com/docs/installation/using-vite如 https://tailwindcss.com/docs/installation/using-vite 所述 this gave me an error about ESM vs CJS for this tailwindcss-vite plugin.这给了我一个关于这个 tailwindcss-vite 插件的 ESM 与 CJS 的错误。

2. Therefore added "type": "module", to the app-local package.json too.因此也在 app-local package.json中添加了"type": "module", 。
3. Renamed my main.scss to main.css as I figured I no longer want to use sass with its compatibility issues with tailwind and its deprecation warnings. Anyways, no real need for sass with tailwind after all. See https://tailwindcss.com/docs/compatibility#sass-less-and-stylus将我的main.scss重命名为main.css ，因为我觉得我不想再使用 sass 了，因为它与 tailwind 存在兼容性问题，并且有弃用警告。不管怎样，tailwind 确实不需要 sass。请参阅https://tailwindcss.com/docs/compatibility#sass-less-and-stylus
4. Add @import "tailwindcss"; to my apps' main.css (replacing the old 3 tailwind import lines as instructed in the documentation).将@import "tailwindcss";添加到我的应用程序的main.css中（按照文档中的说明替换旧的 3 条 tailwind 导入行）。
5. Migrated existing themes, variables, animation keyframes from my tailwind.config.js to the main.css where I import the tailwindcss. See https://tailwindcss.com/docs/theme (Note that this step took some effort as the syntax is very different from javascript, and the nesting too).将现有主题、变量、动画关键帧从tailwind.config.js迁移到main.css ，我在其中导入了 tailwindcss。请参阅https://tailwindcss.com/docs/theme （请注意，此步骤需要一些努力，因为语法与 javascript 非常不同，嵌套也是如此）。
6. Deleted tailwind.config.js and postcss.config.js删除了tailwind.config.js和postcss.config.js
7. npm remove autoprefixer postcss @tailwindcss/postcss sass
8. npm i -D @tailwindcss/vite tailwindcss@latest
9. npx nx reset
10. npx nx sync

Hope I did not forget anything, it should work.希望我没有忘记任何事情，它应该可以起作用。

Thanks, it works.

[benpsnyder]

Our projects have been fighting with Nx Graph stuff for many months. We have to nx reset, rm -Rf node_modules, and jump through hoola hoops (sometimes restart) to get past issues.

When we do have things serving (and its stable for a while at times), its alright. But every so often there are tantrums Nx throws that take a developer out of productivity for hours.

We need better debugging/logging to know what the heck is going on under the sheets.

[BabakScript]

I'm experiencing the same issues for all NX commands. It just waits every time and start the command with a huge delay, see the video below, it waits for a long time and then show the Creating project graph dependencies with 6 plugins message and then run the command, while the command output was in cache from the beginning even the logs show the execution time for command 146ms which is wrong:

https://github.com/user-attachments/assets/a74ccb18-e40d-463c-bce8-dab87fec8042

[esinencodorini]

Same here, in my case I altered project.json for 1 of my apps, nothing on PROBLEMS tabs - hanging every second time on allmost any command :)

[benpsnyder]

+1 for better debug flags and logging so we can post back more helpful feedback to core devs

[monkeytronics]

I'm facing exact same issue with my monorepo. In my case, I just need to refresh the workspace before running a new build or serve etc, and it works. A little inconvenient, but not the end of the world. I'm on nx 20, yarn 4.0.1 and working on an Angular 19 project, with Ionic and Storybook, if any of that is beneficial in the debug efforts? Cheers!

[Ludevik]

Similar issue with: Calculating the project graph on the Nx Daemon is taking longer than expected. Re-run with NX_DAEMON=false to see more details..

It eventually times out:

An error occurred while processing files for the @nx/storybook/plugin plugin (Defined at nx.json#plugins[1])
.
  - Plugin worker @nx/storybook/plugin exited unexpectedly with code null
The "@nx/storybook/plugin" plugin threw an error while creating dependencies: @nx/storybook/plugin timed out after 10 minutes during createDependencies. As a last resort, you can set NX_PLUGIN_NO_TIMEOUTS=true to bypass this timeout.

removing the plugin from nx.json helps. putting it back leads to:

Error: [readCachedProjectGraph] ERROR: No cached ProjectGraph is available.

If you are leveraging \`readCachedProjectGraph()\` directly then you will need to refactor your usage to first ensure that
the ProjectGraph is created by calling \`await createProjectGraphAsync()\` somewhere before attempting to read the data.

If you encounter this error as part of running standard \`nx\` commands then please open an issue on https://github.com/nrwl/nx
    at readCachedProjectGraph (...)

nx reset helps in my case.

[burikella]

I've experienced seemingly the same issue, and was able to workaround it by disabling plugin isolation by setting NX_ISOLATE_PLUGINS to false. I don't see this variable in the documentation, but found it while exploring the source code in effort to diagnose the issue. Could anyone confirm if this helps in your cases?

[roldengarm]

Why doesn't this get any attention from the devs? It's crazy to see all the workarounds being posted. NX used to be rock solid but over the years it has definitely become worse. I spent so much time resetting stuff to get it to work that I'm considering to switch to a different monorepo tool. I've had to reclone my repo 4 times now as well as I couldn't delete the .nx folder due to locking errors.