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

To make it work on GitHub Actions I needed to add code below to package.json I used latest NX version which is v16.5.1 and then run npm install --include=optional

"optionalDependencies": {
  "@nx/nx-darwin-arm64": "16.5.1",
  "@nx/nx-darwin-x64": "16.5.1",
  "@nx/nx-linux-x64-gnu": "16.5.1",
  "@nx/nx-win32-x64-msvc": "16.5.1"
}

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

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

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.

To make it work on GitHub Actions I needed to add code below to package.json I used latest NX version which is v16.5.1 and then run npm install --include=optional

"optionalDependencies": {
  "@nx/nx-darwin-arm64": "16.5.1",
  "@nx/nx-darwin-x64": "16.5.1",
  "@nx/nx-linux-x64-gnu": "16.5.1",
  "@nx/nx-win32-x64-msvc": "16.5.1"
}

This really helped! Thanks

@rmachado-studocu each of the native packages have a specific platform and os field set. See here: https://github.com/nrwl/nx/blob/21007d8922cbf5f0bd2e469d4a5f617364b9dcb3/packages/nx/native-packages/darwin-arm64/package.json#L10-L15

By default, package managers respect these fields and only install packages that match the platform where the install command was ran from.

If you include these types of packages set in your package.json, you need to force your package manager to install packages not meant for your platform.

For example, npm will be npm install --force, yarn will be yarn install --ignore-platform

Had the same issue. I have like 4 repos with Nx (one at work) and one of them had problem after update to 16.8.1

What helped was:

1. removing package-lock.json and node_modules.
2. installing stuff with npm install --include=optional + npm install
3. ✅
4. after that I also run npm dedupe because some deps where not deduplicated

same here, version 16.8.1

I think most of the issues here were solved, nx.dev/recipes/ci/troubleshoot-nx-install-issues will contain information on how to troubleshoot.

Also, if there are folks who are building on a host machine and using a docker container; make sure that the docker container does its own npm install, or --force install the dependencies on the host machine to get all binaries.

If the above solutions do not work for you, please open a new issue.

@Cammisuli Thank you very much for your suggestions 😃

On most of our Agents running our CI there was no Redistributable installed at all (Just the one Windows is bringing by itself) as we were not aware that this is needed we did not install any of those.

I did one run on every machine we use and every Run went through as expected now 😃

I hope it stays that way and if not I will reach out to you here again.

But for now, thank you very much for your help 😃

@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

I am experiencing the same issue running some code using Lerna with version > 7.1.5 and running npm ci on an Azure Pipeline (linux, cloud hosted). (I hope this is not OT, but opening the same bug in the Lerna repo would be not very helpful I guess.)

@Cammisuli ah, using --force revealed the error that the linux package is not compatible with my Windows. So I need to install the dependency inside the container, then it works.

I had same issue, resolved upgrading to 16.5.3

Hi @Cammisuli

Yeah we’re using yarn v3, so our .yarnrc.yml needs to have the supportedArchitectures field configured.

Thanks for the pointers. Now it works as expected 👍

I’m getting an issue related to this on a M2 Pro chip. It only happens when using NX Console, though, not when running commands from the command line.

I had the same issue with the linux-x64 platform as @canibanoglu, @dotrakoun-clearstreet and @martinkamara described in here. Updated to 16.4.2 via npx nx migrate latest and things work again. Maybe that helps you as well?

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

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

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 Repros/_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

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.

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.