nrwl / nx

Smart Monorepos · Fast CI
https://nx.dev
MIT License
23k stars 2.3k forks source link

Command error ^[[12;1R #22358

Open celsomtrindade opened 5 months ago

celsomtrindade commented 5 months ago

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

  1. Install NX 18.1.1 on Windows 10
  2. Create a new Angular project
  3. Try to execute any command (For serve/build or development/production)

During the project creation I got this error message

warning: in the working copy of '.editorconfig', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '.eslintignore', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '.eslintrc.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '.gitignore', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '.prettierignore', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '.prettierrc', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '.vscode/extensions.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'README.md', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/.eslintrc.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/jest.config.ts', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/project.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/app/app.component.html', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/app/app.component.spec.ts', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/app/app.component.ts', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/app/app.config.ts', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/app/app.routes.ts', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/app/nx-welcome.component.ts', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/index.html', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/main.ts', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/styles.scss', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/src/test-setup.ts', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/tsconfig.app.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/tsconfig.editor.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/tsconfig.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'apps/nrwl/tsconfig.spec.json', LF will be replaced by CRLF the next time Git touches itwarning: in the working copy of 'jest.config.ts', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'jest.preset.js', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'nx.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'package-lock.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'package.json', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'tsconfig.base.json', LF will be replaced by CRLF the next time Git touches it

Nx Report

Node   : 20.11.0
OS     : win32-x64
npm    : 10.2.4

nx (global)        : 18.0.1
nx                 : 18.1.1
@nx/js             : 18.1.1
@nx/jest           : 18.1.1
@nx/linter         : 18.1.1
@nx/eslint         : 18.1.1
@nx/workspace      : 18.1.1
@nx/angular        : 18.1.1
@nx/devkit         : 18.1.1
@nx/eslint-plugin  : 18.1.1
@nrwl/tao          : 18.1.1
@nx/web            : 18.1.1
@nx/webpack        : 18.1.1
typescript         : 5.3.3

Failure Logs

Executing task: npx nx run nrwl:serve --configuration=development 

> nx run nrwl:serve:development

^[[12;1R

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

joelpelaez commented 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.

celsomtrindade commented 5 months ago

@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.

joelpelaez commented 5 months ago

@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.

joelpelaez commented 5 months ago

@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.

theneongrey commented 5 months ago

Same issue here. Even with 18.1.2. I got it to run by using --output-style compact.

Dhalias commented 5 months ago

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
S4GU4R0 commented 5 months ago

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)

x-etienne commented 5 months ago

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 ?

JelleBruisten commented 5 months ago

Same issues as already mentioned preventing to upgrade to 18.1 ( coming from 17.x )

x-etienne commented 5 months ago

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

JelleBruisten commented 5 months ago

@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!

rexkenley commented 5 months ago

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.

image

rexkenley commented 5 months ago

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.

image

ak274 commented 4 months ago

This is very critical issue stopping us to update our workspace. Please give a workaround or solution as its been while this exists.

Joredjs commented 4 months ago

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

celsomtrindade commented 4 months ago

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

rexkenley commented 4 months ago

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. image

joelpelaez commented 4 months ago

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. image

@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.

SkyZeroZx commented 4 months ago

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

image

AgentEnder commented 4 months ago

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.

JelleBruisten commented 4 months ago

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.

atsjo commented 4 months ago

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

atsjo commented 4 months ago

Still getting this error with 18.2.4 and the updated pty version for windows

ErickRodrCodes commented 4 months ago

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>"
kris-vista commented 4 months ago

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

rexkenley commented 4 months ago

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.

aikrez commented 4 months ago

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)...
Hollow-Ego commented 4 months ago

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:

AgentEnder commented 4 months ago

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.

ErickRodrCodes commented 4 months ago

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:

image

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.

cayres commented 4 months ago

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

okeydoky commented 4 months ago

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.

JelleBruisten commented 4 months ago

Our ci also runs in Linux, however pressing enter did not resolve it for local development which was on windows.

ardokirsipuu commented 4 months ago

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.

aYorky commented 3 months ago

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.

jdugas commented 3 months ago

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 commented 3 months ago

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.

23039 is available in both the latest v19 betas or the nightly canary release. Once on either of those branches, you can set the env variable 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.

tsmithhisler commented 3 months ago

@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)

tsmithhisler commented 3 months ago

I believe I have a minimal reproducing example repo here: https://github.com/tsmithhisler/nx-repro-22358

AgentEnder commented 2 months ago

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.

SkyZeroZx commented 2 months ago

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

corwestermaniddink commented 1 month ago

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.

AgentEnder commented 1 month ago

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.