This platform (win32-x64) is currently not supported by Nx. after 16.4.0 update

[SteveW94]

Current Behavior

After updating from 16.3.x to 16.4 today, our CI-Pipeline nx-Tasks stopped working with the following message:

" This platform (win32-x64) is currently not supported by Nx."

• The exact same tasks worked perfectly fine before
• yarn.lock has been freshly generated
• Latest node version is used
• The Pipeline runs on an AzureDevops Windows 10 64bit Agent

Expected Behavior

No error messages when using nx-Tasks on Windows 10 CI agent

GitHub Repo

No response

Steps to Reproduce

1. Use nx 16.4 Task in CI pipeline

Nx Report

-

Failure Logs

No response

Operating System

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

Additional Information

No response

[canibanoglu]

I'm having the same issue but on GitHub CI with ubuntu-latest (v22.04.2). Works on my local machine (Mac arm64) and this started happening after the 16.4 update for me too.

Exact error message: This platform (linux-x64) is currently not supported by Nx.

[salihsagdilek]

also same issue digitalocean app platform.

This platform (linux-x64) is currently not supported by Nx.

[Cammisuli]

Oh no! That's not right, linux and Windows are definitely supported. This usually happens because the node_modules directory was installed with the --no-optional flag (or other scenarios).

You can read more about it here: https://nx.dev/recipes/ci/troubleshoot-nx-install-issues#troubleshoot-nx-installations

If things still don't work after following the document, let me know.

[SteveW94]

@Cammisuli

I read about this thorough :)

We make sure that in our CI Pipeline we do always create the node_modules from scratch and Also I re-assured multiple times that we nowhere use the no-optional flag.

Also as I mentioned the same setup works perfectly fine with NX 16.3.2 and stopped working all of a sudden after udpating to 16.4.

[canibanoglu]

We're not using the --no-optional flag at all in the project, our CI does a clean install every time and this started happening after the update to 16.4. We had to revert to the previous version at which point everything started running as they should

[SteveW94]

We're not using the --no-optional flag at all in the project, our CI does a clean install every time and this started happening after the update to 16.4. We had to revert to the previous version at which point everything started running as they should

Exactly same behaviour here :)

[Cammisuli]

Do you all have a reproduction somewhere I can take a look at?

Particularly the package.json and CI commands that are used?

[Cammisuli]

Also, if you take a look inside the node_modules/@nx directory, do you see any packages that are along the lines of nx-platform-arch (eg. nx-win32-x64-msvc)

[SteveW94]

• We run a target with the "nx:run-commands", executor which fails

• The following dependencies we are using and were beforehand 16.3 and got updated to 16.4:

• "@nx/eslint-plugin": "16.4.0", "@nx/js": "16.4.0", "@nx/linter": "16.4.0", "@nx/webpack": "16.4.0", "@nx/workspace": "16.4.0", "nx": "16.4.0", "@nx/angular": "16.4.0",

• In the node_modules @nx directory we have the following folder: nx-win32-x64-msvc

[Cammisuli]

Oh now that's suspicious. The native binary package is there.

We use a Windows agent when we do publishing, so it definitely works on Windows.

I'll see what I can find on a local Windows machine then.

[SteveW94]

Also I just started a run on all our available agents => It seems that not every run is affected...just like 80% or sth...But I am not able to identify why this is the case as ALL machines are the same image

[Cammisuli]

Just for my curiousity @SteveW94, are you running Windows 10 on Azure with On-Premise hosting?

[SteveW94]

Just for my curiousity @SteveW94, are you running Windows 10 on Azure with On-Premise hosting?

It's definatly Windows 10. And yes I am not entirely sure but it could be on-prem hosting AFAIK

[Cammisuli]

What's the install command being used @SteveW94 ?

[SteveW94]

What's the install command being used @SteveW94 ?

This would be:

"yarn install --force --pure-lockfile"

[Cammisuli]

Doesnt seem like I can reproduce the Windows issue. Both locally and on Azure are working for me. Here's the azure run: https://cammisuli.visualstudio.com/Nx%20Repros/_build/results?buildId=24&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=bd05475d-acb5-5619-3ccb-c46842dbc997&l=28

and the repo if you want to change some things to break it: https://github.com/cammisuli/nx-repros

[Cammisuli]

@SteveW94 what version of yarn is being used?

[SteveW94]

@SteveW94 what version of yarn is being used?

v1.22.19 Same as yours 🙈

[Cammisuli]

@SteveW94 can you confirm that all your Windows 10 agents are running with the latest Windows updates? Specifically can you check to see if the msvc redistribution is correct for all of them?

https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

This it the only thing I can think of now, especially because you say that it works on some of your agents.

[creadicted]

I'm having the same issue but on GitHub CI with ubuntu-latest (v22.04.2). Works on my local machine (Mac arm64) and this started happening after the 16.4 update for me too.

Exact error message: This platform (linux-x64) is currently not supported by Nx.

Same. This platform (linux-x64) is currently not supported by Nx. Updated nx with the additional dependencies from the migration.

[FrozenPandaz]

@creadicted What is the command you used to install your npm dependencies? And can you check if node_modules/@nx contains nx-linux-x64-gnu on the Github Actions agent?

[SteveW94]

@SteveW94 can you confirm that all your Windows 10 agents are running with the latest Windows updates? Specifically can you check to see if the msvc redistribution is correct for all of them?

https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

This it the only thing I can think of now, especially because you say that it works on some of your agents.

I will try to verify that and ask the person responsible for the agents image. Can you say how I check the correct msvc redistribution? For which kind of redistributable am I looking for and which version is the latest?

Also what grinds my gears: We did not change anything and with 16.3.2 everything works fine on all agents and 100% of the run, and it starts breaking with 16.4. So at least sth seems to have changed there regarding this?

[martinkamara]

I also got this problem upgrading to latest nx. When I run npm ci on another OS different from where the package-lock.json file was created nx complains about This platform (linux-x64) is currently not supported by Nx.

If i instead run rm package-lock.json && npm install it works. Also nothing has changed in my environments like you @SteveW94

[creadicted]

@FrozenPandaz I use the default script mentioned here https://github.com/nrwl/nx/blob/master/docs/shared/monorepo-ci-github-actions.md

jobs:
  main:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: nrwl/nx-set-shas@v3
      - run: npm ci
      - run: npx nx format:check
        continue-on-error: true
      - run: npx nx affected -t lint --parallel=3
      - run: npx nx affected -t test --parallel=3 --configuration=ci
      - run: npx nx affected -t build --parallel=3

I also got this problem upgrading to latest nx. When I run npm ci on another OS different from where the package-lock.json file was created nx complains about This platform (linux-x64) is currently not supported by Nx.

If i instead run rm package-lock.json && npm install it works. Also nothing has changed in my environments like you @SteveW94

this seems to work

    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: nrwl/nx-set-shas@v3
      - run: rm package-lock.json && npm install
      - run: npx nx format:check

Which odly leads to a library linting fail which can not be reproduced. Not shure if related.

[Cammisuli]

@creadicted & @martinkamara you folks seem to be hitting the npm bug linked here: https://github.com/npm/cli/issues/4828

@SteveW94 We're trying to improve the performance of Nx, and we're compiling rust to be used in Node. With the latest changes, we removed a fallback to Node because we have plans to write more performance oriented code in rust.

In 16.3, we did the same check as we're doing now, but you didnt see the errors before because you were using the Node version.

Now to check what version of msvc is installed, the only thing I saw was to use "Add & Remove programs" and check the version there. I'm not sure of a way to check it in cmd. I'll edit this if I find something.

Here's what I have on Windows 11

[SteveW94]

Thanks for the detailed Information @Cammisuli I will contact our team which maintains the agents to assure that everything is up to date, retest and then reach back to you 👍

[Cammisuli]

~~I found the path to the compiler version - depending on your version some paths might be different, like the year and numbers. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\bin\Hostx64\x64~~

Actually that's the compiler not the redist..

Here it is (powershell):

Get-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x86"

Version      : v14.36.32532.00
Installed    : 1
Major        : 14
Minor        : 36
Bld          : 32532
Rbld         : 0
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x86
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes
PSChildName  : x86
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

cmd:

reg query "HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x86"

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x86
    Version    REG_SZ    v14.36.32532.00
    Installed    REG_DWORD    0x1
    Major    REG_DWORD    0xe
    Minor    REG_DWORD    0x24
    Bld    REG_DWORD    0x7f14
    Rbld    REG_DWORD    0x0

[Cammisuli]

And here's the value that's on Azure (self hosted) https://cammisuli.visualstudio.com/Nx%20Repros/_build/results?buildId=25&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=f8ed7bd8-2a7f-56f6-9385-7fc29a8b5b7b

[creadicted]

@creadicted & @martinkamara you folks seem to be hitting the npm bug linked here: npm/cli#4828 ...

You seem to be correct. Thank you for the link!

[dotrakoun-clearstreet]

node_modules/.pnpm/@[email protected]/node_modules/@parcel/watcher: Running install script, done in 137ms
node_modules/.pnpm/[email protected]/node_modules/nx: Running postinstall script, failed in 206ms
.../.pnpm/[email protected]/node_modules/nx postinstall$ node ./bin/post-install
│  >  NX   Missing Platform Dependency
│    The Nx CLI could not find or load the native binary for your supported platform (linux-x64).
│    This likely means that optional dependencies were not installed correctly, or your system is missing some system dependencies.
│    For more information please see https://nx.dev/recipes/ci/troubleshoot-nx-install-issues
└─ Failed in 206ms at /home/dotrakoun/dev/fleet/src/sovereign/typescript/node_modules/.pnpm/[email protected]/node_modules/nx

still happening for linux-x64

• pnpm 8.6.5

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.5 LTS"

did migrate latest from 16.4.0