Open celsomtrindade opened 5 months ago
Hello, I have the same issue but using PNPM and with express and vite.
Nx Report
Node : 20.11.1
OS : win32-x64
pnpm : 8.15.4
nx (global) : 18.1.1
nx : 18.1.1
@nx/js : 18.1.1
@nx/jest : 18.1.1
@nx/eslint : 18.1.1
@nx/workspace : 18.1.1
@nx/cypress : 18.1.1
@nx/eslint-plugin : 18.1.1
@nx/nest : 18.1.1
@nx/node : 18.1.1
@nx/react : 18.1.1
@nx/vite : 18.1.1
@nx/web : 18.1.1
@nx/webpack : 18.1.1
typescript : 5.3.3
When trying to serve vite project
> nx run frontend:serve
"vite" no se reconoce como un comando interno o externo,
programa o archivo por lotes ejecutable.
Warning: command "vite serve" exited with non-zero status code
———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
NX Running target serve for project frontend failed
Failed tasks:
- frontend:serve
Hint: run the command with --verbose for more details.
When trying to serve express project
> nx run backend:serve:development
Build option outputFileName not set for backend. Using fallback value of dist\apps\backend\main.js.
> nx run backend:build
"webpack-cli" no se reconoce como un comando interno o externo,
programa o archivo por lotes ejecutable.
Warning: command "webpack-cli build --node-env=production" exited with non-zero status code
———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
NX Ran target build for project backend (143ms)
× 1/1 failed
√ 0/1 succeeded [0 read from cache]
Build failed, waiting for changes to restart...
This issue is not present on nx 18.0.8.
This happens when nx is invoked from global or pnpm exec
On PNPM has a workaround: execute nx using npx than global.
@joelpelaez I tried switching back to 18.0.8 but had the same issue. On my macbook air m1 I'm not getting this error and was able to build properly in all apps/libs, for serve/build and develop/production.
Only happening on my windows pc.
Before that I was on version 16 of NX, and that was working just fine on my windows as well.
@celsomtrindade Yes, nx has a lot of issues on Windows platform, many of them related to PNPM, but its because many Node tools are for UNIX platforms.
@celsomtrindade I had the same issue issue like you, when execute the command nx serve fronend
the command freezes and cannot be cancelled with Ctrl+C, only kill the process using Task Manager.
It is possible be an issue related with the pseudo terminals (pty) than supports Windows 10.
I detected other issues related with this, as multiple spawned conhost.exe process than using a lot of CPU.
Same issue here. Even with 18.1.2. I got it to run by using --output-style compact
.
Same issue on my side using the following :
Node : 20.10.0
OS : win32-x64
npm : 10.2.3
nx : 18.1.2
@nx/js : 18.1.2
@nx/jest : 18.1.2
@nx/linter : 18.1.2
@nx/eslint : 18.1.2
@nx/workspace : 18.1.2
@nx/angular : 18.1.2
@nx/cypress : 18.1.2
@nx/devkit : 18.1.2
@nx/eslint-plugin : 18.1.2
@nx/nest : 18.1.2
@nx/node : 18.1.2
@nrwl/tao : 18.1.2
@nx/web : 18.1.2
@nx/webpack : 18.1.2
typescript : 5.3.3
Same issue here. Even with 18.1.2. I got it to run by using
--output-style compact
.
Likewise, I found a workaround for me for now.
I am having the same issue with other targets. In my case, it's dev
.
I was able to get it to work by using the shorthand instead of the full command nx dev <project-name>
(not, nx run <project-name>:dev
)
Hi to all,
same problem here.
It's randomic, sometimes works other not.
like @celsomtrindade I receive ^[[30;1R
, ^[[71;1R
, and so on
Node : 20.10.0
OS : win32-x64
npm : 10.2.5
nx (global) : 18.1.2
nx : 18.1.2
@nx/js : 18.1.2
@nx/jest : 18.1.2
@nx/linter : 18.1.2
@nx/eslint : 18.1.2
@nx/workspace : 18.1.2
@nx/angular : 18.1.2
@nx/devkit : 18.1.2
@nx/esbuild : 18.1.2
@nx/eslint-plugin : 18.1.2
@nx/express : 18.1.2
@nx/node : 18.1.2
@nrwl/tao : 18.1.2
@nx/web : 18.1.2
@nx/webpack : 18.1.2
typescript : 5.3.3
---------------------------------------
thanks
ps: @FrozenPandaz perhaps it is correlated with https://github.com/nrwl/nx/issues/22313 ?
Same issues as already mentioned preventing to upgrade to 18.1 ( coming from 17.x )
As metionate, in https://github.com/nrwl/nx/issues/21779 and https://github.com/nrwl/nx/issues/21838, add
NX_NATIVE_COMMAND_RUNNER=false
on the .env
file on the root of project it mitigate the problem
@x-etienne when I tried earlier versions of nx so 18.0 I did have a .env file but after doing a upgrade to version 18.1 it seems to be removed.
and the setting to use useInferencePlugins
has been moved to nx.json
, I will check if creating such a file and just adding that would work.
edit: seems to work!
I am not sure if this is the fix, but I deleted node_modules and package-lock.json and reran npm i. That took care of the weird text.
Spoke too soon, some projects are still having the weird text issue. This project was generated with the @nx/react - library and @nx/storybook - configuration.
This is very critical issue stopping us to update our workspace. Please give a workaround or solution as its been while this exists.
This is very critical issue stopping us to update our workspace. Please give a workaround or solution as its been while this exists.
Have you tried https://github.com/nrwl/nx/issues/22358#issuecomment-2018082698 ? This should not be a definite solution, but it helps to work without stopping the proccess
As metionate, in #21779 and #21838, add
NX_NATIVE_COMMAND_RUNNER=false
on the
.env
file on the root of project it mitigate the problem
This indeed solved the issue for me, at least for now I can work and compile everything locally. Waiting for a definite fix on this issue before removing .env
1 thing I noticed is that when I start getting the weird text, a "zombie" vscode is running in memory. Once I end that task, the weird text stopped.
1 thing I noticed is that when I start getting the weird text, a "zombie" vscode is running in memory. Once I end that task, the weird text stopped.
@rexkenley Those processes are conhost.exe instances for "headless" pesudoterminals, it's the same concept as pty in UNIX platforms, allows create virtual terminals that I/O is managed by nx using Rust native command runner, but that feature seems buggy on Windows. I detected these first time when using run-many in v18.0.*, when I kill the command using Ctrl-C always leaves some zombie processes that uses a complete CPU core per instance. The noisy CPU fan let me identify that issue.
In that case, if you has NX Visual Studio Code plugin, nx server runs as VSCode child process then Task Manager shows them like that image.
I had a similar error with ^[[18;1 When switch beteween two projects with Angular with Applications Builder ( Based en Vite/Esbuild ) random throw error I use a VS Code Node 18.XX Angular 17
We are actively looking into this, but have been unable to reliably reproduce this. On my windows machine I was able to cause it to happen once, but it went away and I've not been able to get it to occur again.
This isn't to say that its not reliably happening to some number of users, or that there's not a definite cause, just that it makes it harder to nail down.
While we were troubleshooting it, @FrozenPandaz noted that an earlier PR (https://github.com/nrwl/nx/pull/21683) which was meant to fix similar issues had a minor mistake in it as we took some cargo changes for granted. A new PR (https://github.com/nrwl/nx/pull/22711 ) has been put up which will correct those inaccuracies and hopefully make this work smoother.
After that PR has been merged and released, we will have to monitor for issues as we haven't been able to validate the fix ourselves.
Would it matter what version of window's we're using? I am currently on a window 10 machine, which I could reproduce it every time without the .env file.
I can easily reproduce on my win 11 laptop, but not with angular build or serve, or crystal based jest or lint... But I run into this with commands running the firebase cli using @nx:run-commands very often if not setting NX_NATIVE_COMMAND_RUNNER=false
Still getting this error with 18.2.4 and the updated pty version for windows
for those using cross-env
it work fine for me as well without .env:
"start":"cross-env NX_NATIVE_COMMAND_RUNNER=FALSE nx serve <app>"
If it helps, the problem occurrs more often on a lower spec machine (we have a VM that gets it every time) or a machine under load
So far the definitive workaround for the weird text is
1.) Delete .nx/cache 2.) Clear any "zombie" vscode sessions in memory
Things start working again I once I do these 2 things.
Upgraded from 17.2.3 to 18.2.4 and got the error why running nx test for the first time. Consecutive tests ran without problem also after clearing Nx cache
Node : 20.11.0
OS : win32-x64
yarn : 1.22.19
nx : 18.2.4
@nx/js : 18.2.4
@nx/jest : 18.2.4
@nx/linter : 18.2.4
@nx/eslint : 18.2.4
@nx/workspace : 18.2.4
@nx/angular : 18.2.4
@nx/cypress : 18.2.4
@nx/devkit : 18.2.4
@nx/eslint-plugin : 18.2.4
@nx/node : 18.2.4
@nx/plugin : 18.2.4
@nx/storybook : 18.2.4
@nrwl/tao : 18.2.4
@nx/web : 18.2.4
@nx/webpack : 18.2.4
typescript : 5.4.5
When using nx run to start Angular application
^[[6;1R
? Port 4200 is already in use.
Would you like to use a different port? Yes <-- immeditately yes
| Generating browser application bundles (phase: building)...
We encounter the same issue at random. Some of us get stuck with ^[[8;1R
and some with ^[[10;1R
.
We noticed it after upgrading from 15.8.5 to 18.2.3. I think it happens independently of the Editor or IDE, as we've seen it in VSCode and WebStorm.
At least for us it seems to be happening more often in either of those two cases:
nx serve -o
command, checkout to a different branch, then run nx serve -o
againnx serve -o
and immediately cancel, then run it again
We are still looking into this and actively trying to repro, but in the meantime are going to disable the native command runner on windows by default.
We are still looking into this and actively trying to repro, but in the meantime are going to disable the native command runner on windows by default.
One way to reproduce is having a VHD machine with this specs (it happens most of the time):
Powershell Version table:
The configuration belongs Likely to a vmware horizon virtual machine, which is the one I'm using. Unfortunately, I'm not authorized to disclose beyond that.
NX_NATIVE_COMMAND_RUNNER=false works, but you need to write the value in lowercase. The nx code checks if !== 'false', so if anyone has tried to use the cross-env option and got it wrong probably it is because the value is set as FALSE
It seems simply press 'Enter' after these weird characters show up will get the command going. So it's more of annoying than a blocker for us in development. Obviously it will be a totally different story if this happens in CI. Luckily our CI is running on Linux and this issue doesn't seem to affect it.
Our ci also runs in Linux, however pressing enter did not resolve it for local development which was on windows.
I can confirm that pressing Enter works for me too. This was also mentioned at the end of a duplicate issue https://github.com/nrwl/nx/issues/22650. Really strange that it sometimes waits for uses input like that. Maybe it's an useful hint for anyone investigating this.
About reproducing: I'm using the next plugin and have a script "dev": "nx run my-next-ui:serve-dev",
and then just execute yarn dev
and Ctrl+C until it happens. Ctrl+C doesn't exit if it waits for user input (only Ctrl+Pause folowed by task-killing a CPU-hungry leftover process). Sometimes takes 2 retries, sometimes 20.
Just to throw my hat in the ring, I found a workaround of running clear
after the error, and that allows the process to continue.
Problem is, you have to run that every time the error is encountered. Not a great solution in comparison to the other workarounds here, but I discovered that before finding this thread, and maybe, hopefully that will shed a little light on what's going on, or at least add to the evidence pile.
There is a suggestion of NX_NATIVE_COMMAND_RUNNER=false. I understand that works around the issue, but what are the other impacts of setting that value to false?
There's a chance #23039 fixed this, after it we haven't been able to repro on any of our machines which we were able to initially repro it on. That said, its been a flaky issue and before re-enabling the native command runner on windows for everyone, we'd like to ask some of yall to try out the fix.
NX_WINDOWS_PTY_SUPPORT=true
to re-enable the psuedo terminal and see if the issue still occurs. If it does still occur, setting NX_NATIVE_LOGGING=nx::native::pseudo_terminal
will help produce more logs which may be helpful for the continued debugging of the issue.If you do not see the issue reproduce after updating and setting NX_WINDOWS_PTY_SUPPORT=true
, please comment back and let us know so that we can grow confidence that the issue has been resolved and re-enable the native command runner on windows.
There is a suggestion of NX_NATIVE_COMMAND_RUNNER=false. I understand that works around the issue, but what are the other impacts of setting that value to false?
The native command runner runs tasks through a pseudo terminal, which enables Nx to track terminal outputs in a much more accurate way and also enables interactivity. This means even things like vi
or nano
can be used within an Nx target if for some oddball reason you wanted to do so. More practically, it means if a target calls an external CLI, and that CLI prompts for something, you can answer it. Disabling the native command runner reverts Nx to using its builtin handling for outputs tracking that existed prior to v18. It should still work fine, and be mostly indistinguishable, as long as you don't hit one of these edge cases.
After updating, there's not really a reason to set the NX_NATIVE_COMMAND_RUNNER flag anymore though, since its disabled by default on windows now until we figure this out.
@AgentEnder still having issues here with latest beta:
D:\project [main ≡ +0 ~2 -0 !]> npx nx --version
Nx Version:
- Local: v19.0.0-beta.11
- Global: Not found
D:\project [main ≡ +0 ~2 -0 !]> $env:NX_WINDOWS_PTY_SUPPORT="true"
D:\project [main ≡ +0 ~2 -0 !]> $env:NX_NATIVE_LOGGING="nx::native::pseudo_terminal"
D:\project [main ≡ +0 ~2 -0 !]> npx nx run api:serve
TRACE log: Opening Pseudo Terminal
TRACE log: Passing through stdin
TRACE log: Enabling raw mode
TRACE log: Disabling raw mode
> nx run api:serve
TRACE nx::native::pseudo_terminal::rust_pseudo_terminal: nx_fork command: node D:\project\node_modules\nx\src\tasks-runner\fork.js \\.\pipe\nx\C:\Users\tomsm\AppData\Local\Temp\d1c81a415efeb356e7f2\fp39840.sock api:serve
TRACE log: Running node D:\project\node_modules\nx\src\tasks-runner\fork.js \\.\pipe\nx\C:\Users\tomsm\AppData\Local\Temp\d1c81a415efeb356e7f2\fp39840.sock api:serve
TRACE log: Enabling raw mode
TRACE log: Getting running clone
TRACE log: Getting printing_rx clone
TRACE log: spawning thread to wait for command
TRACE log: Returning ChildProcess
TRACE log: Waiting for node D:\project\node_modules\nx\src\tasks-runner\fork.js \\.\pipe\nx\C:\Users\tomsm\AppData\Local\Temp\d1c81a415efeb356e7f2\fp39840.sock api:serve
TRACE log: Quiet: false
TRACE log: Prevented terminal escape sequence ESC[6n from being printed.
The telltale ^[[12;1R
is not present but the process is still hung. Without the environment variables I'm able to run the serve target of my api project.
EDIT: (The process is hung here: https://github.com/nrwl/nx/blob/19.0.0-beta.11/packages/nx/src/tasks-runner/pseudo-terminal.ts#L88 and using process explorer I can see an idle cmd.exe launched with node arguments printed in the log underneath the main nx run api:serve
nodejs process, but no additional nodejs processes like normal)
I believe I have a minimal reproducing example repo here: https://github.com/tsmithhisler/nx-repro-22358
Still aware of this issue - we are keeping an eye on it and spending time as we get it to try to narrow this down.
Currently when updated some version minor of nx 18 not exist again this error for me in windows. Note some days when update other project to nx 19 not show again this error
There is a suggestion of NX_NATIVE_COMMAND_RUNNER=false. I understand that works around the issue, but what are the other impacts of setting that value to false?
@AgentEnder Could you answer this question? I'm curious also.
There is a suggestion of NX_NATIVE_COMMAND_RUNNER=false. I understand that works around the issue, but what are the other impacts of setting that value to false?
The native command runner runs tasks through a pseudo terminal, which enables Nx to track terminal outputs in a much more accurate way and also enables interactivity. This means even things like vi or nano can be used within an Nx target if for some oddball reason you wanted to do so. More practically, it means if a target calls an external CLI, and that CLI prompts for something, you can answer it. Disabling the native command runner reverts Nx to using its builtin handling for outputs tracking that existed prior to v18. It should still work fine, and be mostly indistinguishable, as long as you don't hit one of these edge cases.
After updating, there's not really a reason to set the NX_NATIVE_COMMAND_RUNNER flag anymore though, since its disabled by default on windows now until we figure this out.
Current Behavior
When I run any NX command, such as
nx run admin:build:production
(or development) the console prints the line^[[12;1R
and doesn't proceed.Expected Behavior
Expect the command to execute the build process and finish.
GitHub Repo
No response
Steps to Reproduce
During the project creation I got this error message
Nx Report
Failure Logs
Package Manager Version
No response
Operating System
Additional Information
This error
^[[12;1R
is not always the same, but always similar, such as^[[6;1R
,^[[4;1R
or^[[2;1R