-
Notifications
You must be signed in to change notification settings - Fork 173
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
Race condition when initializing #110
Comments
Fixed in #84 but not released yet. |
chris-olszewski
added a commit
to chris-olszewski/turborepo
that referenced
this issue
Aug 8, 2022
chris-olszewski
added a commit
to chris-olszewski/turborepo
that referenced
this issue
Aug 10, 2022
The corepack step as it exists causes issues if a machine already has corepack enabled and is using the npm shim: ``` olszewski@chriss-mbp cli % make corepack npm install -g corepack@latest Usage Error: This project is configured to use pnpm $ npm ... make: *** [corepack] Error 1 ``` I think we could get around this by changing to a working directory without a packageManager, but that feels very icky. Since we were only upgrading corepack in order to avoid [#110](nodejs/corepack#110) which only happens the first time a user sets up a package manager on a machine, I think this an acceptable regression in order to unblock development. We should follow what comes out of [vercel#157](nodejs/corepack#157) to see if we can add this back eventually.
chris-olszewski
added a commit
to vercel/turborepo
that referenced
this issue
Aug 11, 2022
The corepack step as it exists causes issues if a machine already has corepack enabled and is using the npm shim: ``` olszewski@chriss-mbp cli % make corepack npm install -g corepack@latest Usage Error: This project is configured to use pnpm $ npm ... make: *** [corepack] Error 1 ``` I think we could get around this by changing to a working directory without a packageManager, but that feels very icky. Since we were only upgrading corepack in order to avoid [#110](nodejs/corepack#110) which only happens the first time a user sets up a package manager on a machine, I think this an acceptable regression in order to unblock development. We should follow what comes out of [#157](nodejs/corepack#157) to see if we can add this back eventually.
sounisi5011
added a commit
to sounisi5011/package-version-git-tag
that referenced
this issue
Mar 13, 2023
Old Corepack throws ENOTEMPTY errors (or EPERM errors on Windows) when running package managers in parallel. To fix this, update the old Corepack when it is detected. see nodejs/corepack#110 see nodejs/corepack#84 --------- * 💚 [Debug] Try to switch package managers using Corepack in all Node.js * 💚 [Debug] Run the package manager multiple times * 💚 [Debug] Using the Package Manager in Test * 💚 [Debug] Run package managers in parallel * 💚 Update old Corepack that throws ENOTEMPTY error Old Corepack throws ENOTEMPTY error when running package managers in parallel. This has been fixed in Corepack v0.11, so if the old Corepack is detected, this will be updated. * 💚 Include "XXXXXXXXXXXXX" in the argument of the `mktemp` command The `mktemp` command on GitHub Actions seems to require the specification of the X's. * 💚 Also detects EPERM errors thrown by Corepack On Windows, the old Corepack seems to throw EPERM errors instead of ENOTEMPTY errors. * 💚 Modify comments in shell scripts * 💚 Allow updated Corepack to be used on Windows > ```yaml > # Windows installs global packages to a directory that has lower priority than > # the default node install so we also need to edit $PATH > ``` > Source: https://github.com/vercel/turbo/pull/1632/files#diff-b92a3120126a9ffe46d7d5ec3a8496ef1eac951db09e1972fac7c78438e36c42R62-R63 > ```bash > npm config get prefix >> $GITHUB_PATH > ``` > Source: https://github.com/vercel/turbo/pull/1632/files#diff-b92a3120126a9ffe46d7d5ec3a8496ef1eac951db09e1972fac7c78438e36c42R69 * 💚 Update npm without using npm-windows-upgrade This step was added with #185. However, perhaps if we run `npm config get prefix >> "${GITHUB_PATH}"`, we can update npm with the `npm install --global npm` command. * 💚 [Debug] Try updating npm on Windows without updating the environment variable `$PATH` * ⏪ Revert "💚 [Debug] Try to switch package managers using Corepack in all Node.js" This reverts commit 5b4ec7c, 3a62968, 977b430, and 281b88a. * ✅ [Debug] Verify npm version * ⏪ Revert "✅ [Debug] Verify npm version" This reverts commit c9ddd9d. * ✅ [Debug] Verify npm version * ⏪ Revert "💚 [Debug] Try updating npm on Windows without updating the environment variable `$PATH`" This reverts commit 919029c. * 💚 Modify the display content of "Enable Corepack" job * 💚 Use the prefix "[command]" together with the command `sleep 1` * 💚 Use the `node -e 'setTimeout(()=>0,10)'` command instead of the `sleep 1` command Waiting two seconds just to correct a display shift is a waste of time. Note: The POSIX-compliant `sleep` command has a minimum of one second, so we use the `node` command instead. * 💚 [Debug] Try updating npm on Windows without updating the environment variable `$PATH` * ⏪ Revert "💚 [Debug] Try updating npm on Windows without updating the environment variable `$PATH`" This reverts commit 96914e1. * ⏪ Revert "✅ [Debug] Verify npm version" This reverts commit 70250e2. * 💚 Modify the display content of "Enable Corepack" job * 💚 Rewrite `exec_with_debug` function from Bash to Node.js * 💚 Fix the bash here-document * 💚 [Debug] Try updating npm on Windows without updating the environment variable `$PATH` * ⏪ Revert "💚 [Debug] Try updating npm on Windows without updating the environment variable `$PATH`" This reverts commit 481b3a0. * 💚 Wrap complex code that detects old Corepack in a function * 💚 [Debug] Try to switch package managers using Corepack in all Node.js * 💚 [Debug] Try without updating old Corepack * ⏪ Revert "💚 [Debug] Try without updating old Corepack" This reverts commit 1631259. * ⏪ Revert "💚 [Debug] Try to switch package managers using Corepack in all Node.js" This reverts commit 6fd6ece. * 📝 Update CHANGELOG
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When you have different projects that run yarn for the first time at the same time, there's a race condition and some of them fail.
Corepack should handle initializing yarn from more than 1 project at the same time because it is common when setting up from scratch.
The text was updated successfully, but these errors were encountered: