Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[turborepo] 1.7.0 with yarn berry doesn't work #3280

Closed
kyun opened this issue Jan 12, 2023 · 15 comments · Fixed by #3744
Closed

[turborepo] 1.7.0 with yarn berry doesn't work #3280

kyun opened this issue Jan 12, 2023 · 15 comments · Fixed by #3744
Labels
kind: bug Something isn't working

Comments

@kyun
Copy link

kyun commented Jan 12, 2023

What version of Turborepo are you using?

1.7.0

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

Yarn v2/v3 (node_modules linker only)

What operating system are you using?

Mac

Describe the Bug

I've upgraded turbo version 1.6.3 -> 1.7.0.

I've got error like this

thread 'main' panicked at 'Failed to execute turbo.: Os { code: 2, kind: NotFound, message: "No such file or directory" }', crates/turborepo/src/main.rs:23:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected Behavior

It should be work well like 1.6.3

To Reproduce

.yarnrc.yml

nodeLinker: pnp
yarn set version berry
yarn add turbo@1.7.0
yarn dev

Reproduction Repo

No response

@kyun kyun added area: turborepo kind: bug Something isn't working labels Jan 12, 2023
@tknickman
Copy link
Member

Reproduced, thanks for the issue - we're taking a look.

@tknickman
Copy link
Member

tknickman commented Jan 12, 2023

@kyun you can unblock by using nodeLinker: node-modules, but we've identified the issue and are looking into solutions for installing with pnp on our end.

darthtrevino added a commit to microsoft/showwhy that referenced this issue Jan 12, 2023
@alexghr
Copy link

alexghr commented Jan 12, 2023

Hey, just to add to this: I'm seeing the same thing when using pnpm@7.24.3 and turbo@1.7.0. I've tried with node-linker=hoisted but I still get the same error.

@tknickman
Copy link
Member

@alexghr could you provide a reproduction? I'm not seeing any issues with pnpm@7.24.3 locally so want to make sure I'm testing correctly.

@alexghr
Copy link

alexghr commented Jan 12, 2023

Hmm, my weird environment might also be at fault. My machine runs NixOS so ever since Turbo switched to a pre-compiled binary I can't install it directly from npm (see #2556 and #2293). I'm using TURBO_BINARY_PATH to tell the JS wrapper where the binary is and I install the binary through a Nix flake (so that I can patch it for my system).

I've pushed a branch to this test repo here https://github.com/alexghr/turbo.nix-test/tree/turbo-1.7.0+pnpm. The files are copy-pasted from the create-turbo-app template, to which I've added flake.nix so that I could install turbo.

Commands like turbo --version and turbo --help do work with this setup.

@tknickman
Copy link
Member

tknickman commented Jan 12, 2023

Awesome, thanks @alexghr I'll take a look.

One note, for 1.7.0 there are two binaries now that need to be colocated. turbo and go-turbo

@teamchong
Copy link

teamchong commented Jan 13, 2023

image

it looks like the go-turbo binary is missing in the "yarn bin turbo" folder
as a temporary workaround, I set the TURBO_BINARY_PATH manually in package.json

"build": "TURBO_BINARY_PATH=$(echo \"console.log(require('child_process').execSync('find .yarn/unplugged/turbo-'+process.platform+'-'+process.arch.replace(/^x/,'')+'-* -name turbo').toString())\" | node) turbo run build"

@geauser
Copy link

geauser commented Jan 16, 2023

I use yarn PnP in a monorepo and I have the same issue.
Using a globally installed version of turbo work fine for now:

npm install turbo -g

NB: make sure to remove the locally installed version of turbo

@geauser
Copy link

geauser commented Jan 16, 2023

image

it looks like the go-turbo binary is missing in the "yarn bin turbo" folder as a temporary workaround, I set the TURBO_BINARY_PATH manually in package.json

"build": "TURBO_BINARY_PATH=$(echo \"console.log(require('child_process').execSync('find .yarn/unplugged/turbo-'+process.platform+'-'+process. Arch+'-* -name turbo').toString())\" | node) turbo run build"

@teamchong I think you made a typo error, it should be:

TURBO_BINARY_PATH=$(echo \"console.log(require('child_process').execSync('find .yarn/unplugged/turbo-'+process.platform+'-'+process.arch.replace('x', '')+'-* -name turbo').toString())\" | node) turbo run build

(note the process.arch instead of process. Arch))

Also, I needed to remove the x in x64 so I added .replace('x', '').

@alexghr
Copy link

alexghr commented Jan 18, 2023

One note, for 1.7.0 there are two binaries now that need to be colocated. turbo and go-turbo

Ah that was the problem! Well, in the meantime, @joedevivo opened alexghr/turborepo.nix#1 to add the new binary and everything is working perfectly with pnpm and turbo 1.7.0 :)

@kyun
Copy link
Author

kyun commented Jan 18, 2023

Does Turborepo support PnP mode officially?

@tknickman
Copy link
Member

@kyun it does not. Officially we support node_modules linker only. However it looks like we made things worse in 1.7.0 so we have that on our radar.

tknickman added a commit that referenced this issue Feb 10, 2023
This improves yarn berry support when using `nodeLinker: pnp` by using
the correct binary path for the child process. This ensure our rust
binary is can correctly find the go binary.

Fixes #3280
@tknickman
Copy link
Member

This should be fixed in turbo@1.7.5-canary.0

@kyun
Copy link
Author

kyun commented Feb 11, 2023

This should be fixed in turbo@1.7.5-canary.0

I know it isn't official support yet but do you recommend using PnP mode with turbo?

@Brew-Brew
Copy link

@tknickman Turborepo supports yarn berry with pnp mode..? I heard that it doesn't support , but it works on my repo. so i want to know official response for this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants