The latest updates on your projects. Learn more about Vercel for Git ↗︎

@atimmer is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

Hey, thanks for the contribution! I unfortunately tried this with Yarn 1 and it doesn't work there. So we'd be trading Yarn 1 for Yarn 4. 😄

Is it possible you could run yarn --version prior to that code block and then fork the behavior based on the version that comes back? I know that adds some difficulty to things but I'd like to be making an explicit move towards completeness than trading one for the other.

(Alternatively, if you'd like to leave it to me to pick up what you've written here and adapt it for those requirements, I can do that as well. I've had it happen to me where I tried to submit a PR and the maintainer asked for more and I thought "I had time for the simple way, not the hard way", so I'd completely understand. However, some folks like to see their name in the release notes so don't want to take that away from you!)

@anthonyshew It seems like there was already a code block for detecting the Yarn version. And somehow I put the change in the wrong one, oops. Because I wasn't able to test this I didn't detect this. I have now rebased the PR to put the codeblock in the correct position. This assumes that there is no difference between Yarn 2, 3 and 4 in this regard.

(Alternatively, if you'd like to leave it to me to pick up what you've written here and adapt it for those requirements, I can do that as well. I've had it happen to me where I tried to submit a PR and the maintainer asked for more and I thought "I had time for the simple way, not the hard way", so I'd completely understand. However, some folks like to see their name in the release notes so don't want to take that away from you!)

In any case you can always take my code and make it shippable. My name in the release notes is not that important to me. My main concern is improving the project and removing a small annoyance from my workflow 😄

Hi! 👋 I've run into this issue as well and was looking to fix it before seeing that this issue already existed.

I found that even though this code technically works:

case "yarn":
      // yarn 2.x and 3.x (berry)
      if (gte(packageManagerVersion, "2.0.0")) {
        return renderCommand([
          "yarn",
          "add",
          `turbo@${to}`,
          installType === "devDependencies" && "--dev",
        ]);
        // yarn 1.x
      }
      return renderCommand([
        "yarn",
        "add",
        `turbo@${to}`,
        installType === "devDependencies" && "--dev",
        isUsingWorkspaces && "-W",
      ]);

The packageManagerVersion gotten in the getAvailablePackageManagers method does not seem to be correct since it's running on a tmp directory instead of the repository root. According to Yarn's documentation, its binary preferably should be on each repository. So this way, when I run @turbo/codemod update on my repository which has a local Yarn version, it detects version 1 (that is installed by default globally) when it should be the local version 4.

I found that if I disable running on tmp folder for each command, the returned version is actually correct:

async function exec(command: string, args: Array<string> = [], opts?: Options) {
  // run the check from tmpdir to avoid corepack conflicting -
  // this is no longer needed as of https://github.com/nodejs/corepack/pull/167
  // but we'll keep the behavior for those on older versions)
  const execOptions: Options = {
    // REMOVE THIS LINE HERE
    // cwd: os.tmpdir(),
    env: { COREPACK_ENABLE_STRICT: "0" },
    ...opts,
  };
  try {
    const { stdout } = await execa(command, args, execOptions);
    return stdout.trim();
  } catch {
    return undefined;
  }
}

But I'm unaware if this breaks other package managers. @anthonyshew do you think this is a viable fix?

@tomcastro It may be. Could you open up a separate PR with that so I can take a look at it?

@anthonyshew sure thing, created this PR

@atimmer, hope you don't mind but I'm going to try something on this PR.

It looks like you're both on the right track:

• We're finding the wrong binary for yarn berry versions. The tmpdir meant we were exiting the repository's context, so we could never find yarn 2+ (since they don't allow(? encourage?) global installations).
• This meant we were calling the wrong command. The -W is right for yarn 1, so we were trying to use it, even though the repo is berry.

I've tacked on a couple commits that I think should level out these behaviors and have hand tested this implementation on my machine. I'm going to ask a teammate to look this over because:

1. These package-manager-binary-finding things are finnicky.
2. The tests were passing before, and still are now. I believe this is because our tests don't run against real package manager installations, but haven't been able to confirm. I think I see it in the mocks but not certain.

@anthonyshew awesome! let us know if we can help with anything else 🙌