[turborepo] v1.7.0 throws "Failed to find package "turbo-linux-64" on the file system" in CircleCI pipeline

[andremonteiro95]

What version of Turborepo are you using?

1.7.0

What package manager are you using / does the bug impact?

npm

What operating system are you using?

Linux

Describe the Bug

After updating to version 1.7.0, our CircleCI pipelines have started failing due to the following error:

[turbo] Failed to find package "turbo-linux-64" on the file system

Expected Behavior

The pipeline should have continued working as usual.

To Reproduce

Below you can find the full logs for the npm ci command:

npm ERR! code 1
npm ERR! path /home/circleci/repo/node_modules/turbo
npm ERR! command failed
npm ERR! command sh -c -- node install.js
npm ERR! [turbo] Failed to find package "turbo-linux-64" on the file system
npm ERR! 
npm ERR! This can happen if you use the "--no-optional" flag. The "optionalDependencies"
npm ERR! package.json feature is used by turbo to install the correct binary executable
npm ERR! for your current platform. This install script will now attempt to work around
npm ERR! this. If that fails, you need to remove the "--no-optional" flag to use turbo.
npm ERR! 
npm ERR! node:internal/modules/cjs/loader:1039
npm ERR!   const err = new Error(message);
npm ERR!               ^
npm ERR! 
npm ERR! Error: Cannot find module 'turbo'
npm ERR! Require stack:
npm ERR! - /home/circleci/repo/node_modules/turbo/node-platform.js
npm ERR! - /home/circleci/repo/node_modules/turbo/install.js
npm ERR!     at Module._resolveFilename (node:internal/modules/cjs/loader:1039:15)
npm ERR!     at Function.resolve (node:internal/modules/cjs/helpers:109:19)
npm ERR!     at downloadedBinPath (/home/circleci/repo/node_modules/turbo/node-platform.js:44:44)
npm ERR!     at checkAndPreparePackage (/home/circleci/repo/node_modules/turbo/install.js:285:15)
npm ERR!     at Object.<anonymous> (/home/circleci/repo/node_modules/turbo/install.js:310:1)
npm ERR!     at Module._compile (node:internal/modules/cjs/loader:1218:14)
npm ERR!     at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
npm ERR!     at Module.load (node:internal/modules/cjs/loader:1081:32)
npm ERR!     at Module._load (node:internal/modules/cjs/loader:922:12)
npm ERR!     at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) {
npm ERR!   code: 'MODULE_NOT_FOUND',
npm ERR!   requireStack: [
npm ERR!     '/home/circleci/repo/node_modules/turbo/node-platform.js',
npm ERR!     '/home/circleci/repo/node_modules/turbo/install.js'
npm ERR!   ]
npm ERR! }
npm ERR! 
npm ERR! Node.js v18.13.0

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/circleci/.npm/_logs/2023-01-16T11_59_02_171Z-debug-0.log

Exited with code exit status 1

Reproduction Repo

No response

[jdchmiel]

Seeing this on an m1 mac too.

[alexkrolick]

Workaround for me was to make sure the package installs both architectures in the lockfile, so that npm ci doesn't get confused when it attempts a frozen-lockfile install and turbo wants its platform specific optional deps:

npm install -D --arch=x64 --platform=linux turbo
npm install -D --arch=arm64 --platform=darwin turbo

Further details https://sharp.pixelplumbing.com/install#cross-platform

This should be much better documented because it's a very common problem when using different architectures for dev and CI.

[mscharley]

The better documentation is helpful, but this keeps coming up every time the package gets updated and we need to re-patch the package-lock again with both platform/arch's. Is there any way to tell the package to install multiple pre-build binaries consistently?

[alexkrolick]

• Yarn, yes: https://yarnpkg.com/configuration/yarnrc#supportedArchitectures
• PNPM, no: workaround
• NPM, no: workaround above

[flaviostutz]

I am facing the same issue as mentioned.

In our case we have to use "--no-optional" flag because of some issues we have with another library and Turbo isn't running in our CI environment, so I am in a dead end here. I've just migrated from NX to Turbo because it was cleaner, but this became a real mess for us

The behavior in our CI linux64 based vms is different from in my machine:

In my machine (Macbook darwin64):

• I cleaned up node_modules
• run yarn install --no-optional (I am using Yarn classic)
• run "yarn turbo" and it worked (I don't have it installed globally, so if I remove node_modules and try again it doesn't find turbo, as expected)
• I can see it created in node_modules only the "optional" folder "turbo-darwin-64"

I expected this same behavior would happen on our linux64 machines, but it failed with the mentioned message "Failed to find package turbo-linux-64...".

Why does it work on Mac, but not on Linux64? Do you think this is a bug?

[alexkrolick]

yarn install --no-optional

@flaviostutz The alternate platforms are optional deps, so remove that flag if you can. You might be able to work around it by configuring .yarnrc as mentioned above:

# .yarnrc.yml
supportedArchitectures:
  os:
    - darwin
    - linux
  arch:
    - arm64
    - x64

It's not really clear to me how this isn't more of an issue. Is yarn the preferred tool? Is the expectation that everyone will set up supportArchitectures like that?

The turbo repo GitHub action itself seems to bypass the issue by globally installing turbo@<pinned_version> instead of using package.json. https://github.com/vercel/next.js/blob/canary/.github/workflows/build_test_deploy.yml#L942 This doesn't seem ideal because the workflow file and package.json can easily get out of sync, and it unpins all the sub-dependencies brought in by turbo by bypassing the lockfile.

[flaviostutz]

Yes, the thing is that I cannot use ignore optional and I am using Yarn 1, which doesn't have these configurations :/

[Ketcap]

Hey guys I've find a way to work with this, because your machine is M1 probably (it was for me in this case), package-lock generated on your pc is different then the source machine. So to get around with that you can use command below so it will not depend on package-lock but install clean so it will use the build machine specs.

npm i --package-lock=false

Just 'npm i"

After change

Hope it helps  👍

[alexkrolick]

@Ketcap unfortunately installing without package-lock in CI makes your builds slower and non-deterministic because the subdependencies of your packages will be re-resolved for each install. This presents a security issue as well because you don't have visibility into what packages are actually installing each time.

[Ketcap]

@Ketcap unfortunately installing without package-lock in CI makes your builds slower and non-deterministic because the subdependencies of your packages will be re-resolved for each install. This presents a security issue as well because you don't have visibility into what packages are actually installing each time.

You are right! But right now this is the only way to bypass this issue if it's required. I have the same issue unfortunately and this is the only way of making it work. In my case my project is side-project so I don't care that much.

[nathanhammond]

The root cause is likely this: npm/cli#4828

If you regenerate your lockfile after removing the existing node_modules it will fix itself.

[nathanhammond]

I'm going to go ahead and lock this; if you are still encountering problems, please open a new issue! We'll be happy to look again.