-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Yarn Berry Turbo Prune minor incorrectness #2049
Comments
Thanks for the report. Is there any chance you could get me the entries that reference the other versions of |
Are the entries for |
Pre-prune, there are no references to >=12, meros/commitlint post-prune. I will try and put together a better reproduction if possible tomorrow/this weekend. Thanks! |
Hey @quinnturner, any chance you could get me all of the pre-prune lockfile entries that reference |
@chris-olszewski I have created a documented reproduction and invited you to the private GitHub repository. Expect an email for approval! The reproduction is on v1.5.6. |
@quinnturner, thank you so much for the reproduction. I just put up #2269 which fixes 2/3 changes, the final one comes from the turbo not fully understanding how the |
(Targeting 1.6.1 with this one.) |
Partially addresses #2049 Yarn 2+ doesn't expect descriptors that appear in `peerDependencies` to be kept. This behavior only manifested in a lockfile where a pruned package had a normal dependency descriptor that also appeared as a peer dependency descriptor in a package that wasn't pruned. As background "descriptor" is the term Yarn uses for a semver range that appears in a `package.json` or lockfile entry. Amended the minimal berry lockfile to now test that we don't keep around descriptors even if they appear in `peerDependencies`.
@chris-olszewski Appreciate the good work! We're also running into the same issue as mentioned above, with both resolutions and peerDependencies. This is currently blocking our transition into Yarn 2, are there any easy workarounds in the meanwhile? |
@PatrickLef in my opinion, use --no-immutable until all Yarn Berry lockfile issues are resolved. There are so few inconsistencies now that the added risk of having the installation mutable likely doesn't increase security concern scope. |
I am closing this ticket now as the issues initially outlined have been resolved except for |
What version of Turborepo are you using?
v1.5.1v1.5.6What 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
First, congrats to @chris-olszewski on implementing this feature; it is a challenging engineering problem!
I tried to prune my pretty extensive monorepo, and it was so close to supporting
--immutable
. Here is the diff after runningyarn
:Where the usages of
@types/node >= 12
are as follows:It also got a
patch
slightly incorrect, but you noted that in the feature PR description. The patch does not seem to be related to the@types/node
issue.Expected Behavior
The prune to produce a lockfile that supports the
--immutable
flag.To Reproduce
Unfortunately, I can't share the lockfile over here. If you're interested in a proper reproduction it will take some time to isolate the specific issue.
Best of luck!
The text was updated successfully, but these errors were encountered: