[turborepo] Turbo prune failing #3638
Assignees
Labels
kind: bug
Something isn't working
Comments
chris-olszewski
added a commit
that referenced
this issue
Feb 7, 2023
Fixes #3638 I added a regression in #3611 where we would error if there was a specifier mismatch and the specifier wasn't totally resolved. This was an unintended change to the previous behavior would indicate it didn't find a package resolution. Tested against [provided reproduction](https://github.com/sushiswap/sushiswap)
chris-olszewski
added a commit
that referenced
this issue
Apr 14, 2023
### Description This is a follow up to #4541 that fixes the underlying issue. We now will attempt to return the extracted version instead of the full key when we encounter one. A quick explanation for how this happened is that when [pnpm aliases](https://pnpm.io/aliases) are used the resolved version in the lockfile will be the full lockfile key instead of a version since the name won't match the specifier (e.g. `"foo: npm:bar@^1.0.0"` will have a version of `/bar/1.0.0` instead of just `1.0.0`). This is all fine unless an external dependency also depends on `[email protected]` then we get a dependency of `Package{Key: "/bar/1.0.0", Version: "1.0.0"}` when going through the external dependency where we would get `Package{Key: "/bar/1.0.0", Version: "/bar/1.0.0"}` going through the workspace with the alias. ### Testing Instructions Updated the unit test added in the initial PR to reflect that we're no longer getting a package with a version that's actually a lockfile key. This change also changes the test for pnpm overrides, but this change is more correct as we're now only returning the version. I also tested that the changes don't trigger the repro that was provided in #3638
NicholasLYang
pushed a commit
to NicholasLYang/turbo
that referenced
this issue
Apr 21, 2023
### Description This is a follow up to vercel#4541 that fixes the underlying issue. We now will attempt to return the extracted version instead of the full key when we encounter one. A quick explanation for how this happened is that when [pnpm aliases](https://pnpm.io/aliases) are used the resolved version in the lockfile will be the full lockfile key instead of a version since the name won't match the specifier (e.g. `"foo: npm:bar@^1.0.0"` will have a version of `/bar/1.0.0` instead of just `1.0.0`). This is all fine unless an external dependency also depends on `[email protected]` then we get a dependency of `Package{Key: "/bar/1.0.0", Version: "1.0.0"}` when going through the external dependency where we would get `Package{Key: "/bar/1.0.0", Version: "/bar/1.0.0"}` going through the workspace with the alias. ### Testing Instructions Updated the unit test added in the initial PR to reflect that we're no longer getting a package with a version that's actually a lockfile key. This change also changes the test for pnpm overrides, but this change is more correct as we're now only returning the version. I also tested that the changes don't trigger the repro that was provided in vercel#3638
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Turborepo are you using?
1.7.3
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Linux
Describe the Bug
Our CD started failing after the introduction of [email protected], which we're using to prune the monorepo to reduce size. It looks like it's got to do with a specific dependency, namely
@nomiclabs/hardhat-ethers@npm:[email protected], though[email protected]appears in the log as well.Tested on 1.7.0-1.7.2, works perfectly there.
Expected Behavior
To Reproduce
Reproduction Repo
http://github.com/sushiswap/sushiswap
The text was updated successfully, but these errors were encountered: