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.

Sign up for GitHub

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

Jump to bottom

[Bug?]: yarn install fails during 'Post-resolution validation' after upgrade to 4.0 #5841

Closed
1 task
eigilsagafos opened this issue Oct 24, 2023 · 7 comments · Fixed by #6205
Closed
1 task

[Bug?]: yarn install fails during 'Post-resolution validation' after upgrade to 4.0 #5841

eigilsagafos opened this issue Oct 24, 2023 · 7 comments · Fixed by #6205
Labels
bug Something isn't working

Comments

@eigilsagafos
Copy link

Self-service

  • I'd be willing to implement a fix

Describe the bug

After upgrading to yarn 4 and running yarn install I get the following error:

➤ YN0000: ┌ Post-resolution validation
➤ YN0001: │ TypeError: Cannot read properties of null (reading 'set')
    at /.yarn/releases/yarn-4.0.0.cjs:140:118086
    at Array.map (<anonymous>)
    at sM (/.yarn/releases/yarn-4.0.0.cjs:140:118074)
    at /.yarn/releases/yarn-4.0.0.cjs:207:6475
    at Array.map (<anonymous>)
    at FAt (/.yarn/releases/yarn-4.0.0.cjs:207:6070)
    at /.yarn/releases/yarn-4.0.0.cjs:213:2771
    at Lt.startSectionPromise (/.yarn/releases/yarn-4.0.0.cjs:176:2834)
    at Lt.startTimerPromise (/.yarn/releases/yarn-4.0.0.cjs:176:3734)
    at St.install (/.yarn/releases/yarn-4.0.0.cjs:213:2697)

To reproduce

This is a huge private monorepo. I'm aware that this might get closed due to no way to reproduce, but I am posting in case others have the same issue and could add more context.

Note: The doc link in this issue template to https://yarnpkg.com/advanced/sherlock is broken

Environment

System:
    OS: macOS 14.0
    CPU: (10) arm64 Apple M1 Max
  Binaries:
    Node: 19.9.0 - /private/var/folders/1h/8llh51vx1s1g998jrmj8_qg80000gn/T/xfs-68ee2d4f/node
    Yarn: 4.0.0 - /private/var/folders/1h/8llh51vx1s1g998jrmj8_qg80000gn/T/xfs-68ee2d4f/yarn
    npm: 9.6.3 - ~/.local/share/nvm/v19.9.0/bin/npm

Additional context

No response
@eigilsagafos eigilsagafos added the bug Something isn't working label Oct 24, 2023
@arcanis
Copy link
Member

arcanis commented Oct 24, 2023

Hm - can you try running yarn set version from sources --no-minify to have a more readable stacktrace and be able to add console.log around the relevant lines?

@eigilsagafos
Copy link
Author

@arcanis I'm working on it and will update soon.

Another sidenote, it worked to get the non minified version, however the install ends with an error

Unknown Syntax Error: Unsupported option name ("--no-minify").

$ ... <pluginName>
➤ YN0001: Child yarn reported an error
➤ YN0001:   Exit Code: 1
➤ YN0000: Failed with errors in 42s 368ms

@eigilsagafos
Copy link
Author

So the problem was that we have been using workspace:packages/name some places instead of workspace:* (I don't remember why we have been using that pattern, but it worked in yarn 3). The validRange function returned ["workspace:packages/name"] in the simplifyRanges function resulting in the crash. I was able to complete the install without errors when I changed all the internal package references to workspace:*.

@MrDockal
Copy link

Hello I'm having the same problem. Basically, we have two monorepos and I'd like to link packages from one monorepo to another using yarn link /path/to/package/in/monorepo --all

After a quick investigation the error occurs here

berry/packages/yarnpkg-core/sources/semverUtils.ts

Line 207 in 017b94a

const parsedRanges = ranges.map(range => validRange(range)!.set.map(comparators => comparators.map(comparator => getComparator(comparator))));

I can try to reproduce the issue

@izifortune
Copy link

Having the same issue here we are not using the workspace:packages/name

@noahnu
Copy link
Contributor

noahnu commented Mar 8, 2024

I just run into this as well. I patched Yarn to add some debug logging to see if I can trace down what's happening.

In my code, I was programmatically using Yarn (as part of the monoweave project). In monoweave, we update the version ranges in the package.jsons and then call:

await project.install({
    cache,
    report,
    immutable: false,
})

it ends up there was a bug in monoweave which caused one of the dependency ranges to be set to a value which produced peer dependency warnings. In emitPeerDependencyWarnings, we collect ranges and pass them to simplifyRanges which ultimates passes each range to validRange:

https://github.com/yarnpkg/berry/blob/2aa53d144c2e0fed8792032ce8655a34116a15f7/packages/yarnpkg-core/sources/Project.ts#L2652C11-L2652C20

one of the peer dependency ranges being passed in was a workspace protocol: workspace:1.2.3. This was converted to "null" via validRange which caused the error.

In my case, once I fixed my invalid peer dependencies, the error went away. This does seem to imply some sort of bug or lack of error handling in the emitPeerDependencyWarnings function though.

Full stack trace (semverUtils.js:188 points to validRange).

Post-resolution validation
➤ YN0001: │ TypeError: Cannot read properties of null (reading 'set')
    at /home/runner/.yarn/berry/cache/@yarnpkg-core-patch-09dbe5b5d6-10.zip/node_modules/@yarnpkg/core/lib/semverUtils.js:188:63
    at Array.map (<anonymous>)
    at Object.simplifyRanges (/home/runner/.yarn/berry/cache/@yarnpkg-core-patch-09dbe5b5d6-10.zip/node_modules/@yarnpkg/core/lib/semverUtils.js:188:33)
    at /home/runner/.yarn/berry/cache/@yarnpkg-core-patch-09dbe5b5d6-10.zip/node_modules/@yarnpkg/core/lib/Project.js:1982:43
    at Array.map (<anonymous>)
    at emitPeerDependencyWarnings (/home/runner/.yarn/berry/cache/@yarnpkg-core-patch-09dbe5b5d6-10.zip/node_modules/@yarnpkg/core/lib/Project.js:1969:100)
    at /home/runner/.yarn/berry/cache/@yarnpkg-core-patch-09dbe5b5d6-10.zip/node_modules/@yarnpkg/core/lib/Project.js:1305:13
    at StreamReport.startSectionPromise (/home/runner/.yarn/berry/cache/@yarnpkg-core-patch-09dbe5b5d6-10.zip/node_modules/@yarnpkg/core/lib/StreamReport.js:239:26)
    at StreamReport.startTimerPromise (/home/runner/.yarn/berry/cache/@yarnpkg-core-patch-09dbe5b5d6-10.zip/node_modules/@yarnpkg/core/lib/StreamReport.js:289:21)
    at Project.install (/home/runner/.yarn/berry/cache/@yarnpkg-core-patch-09dbe5b5d6-10.zip/node_modules/@yarnpkg/core/lib/Project.js:1302:27)
➤ YN0000: │ └ Completed

noahnu added a commit to monoweave/monoweave that referenced this issue Mar 8, 2024
@noahnu
fix: handling of pre-v0.1 when coercing implicit peer dependencies to…
d92b4cc 
… minor

Previously, monoweave would throw an error if coerceImplicitPeerDependency was set to minor and a workspace peer dependency was pre-v0.1. This is because the version 0.0.x would get coerced to 0.0.0 resulting in the SemVer range of ^0.0.0. This range does not match anything, resulting in invalid peer dependencies. Related to yarnpkg/berry#5841.
@noahnu noahnu mentioned this issue Mar 8, 2024
Merged
noahnu added a commit to monoweave/monoweave that referenced this issue Mar 8, 2024
@noahnu
fix: handling of pre-v0.1 when coercing implicit peer dependencies to…
e3df391 
… minor

Previously, monoweave would throw an error if coerceImplicitPeerDependency was set to minor and a workspace peer dependency was pre-v0.1. This is because the version 0.0.x would get coerced to 0.0.0 resulting in the SemVer range of ^0.0.0. This range does not match anything, resulting in invalid peer dependencies. Related to yarnpkg/berry#5841.
noahnu added a commit to monoweave/monoweave that referenced this issue Mar 8, 2024
@noahnu
fix: handling of pre-v0.1 when coercing implicit peer dependencies to…
400159b 
… minor

Previously, monoweave would throw an error if coerceImplicitPeerDependency was set to minor and a workspace peer dependency was pre-v0.1. This is because the version 0.0.x would get coerced to 0.0.0 resulting in the SemVer range of ^0.0.0. This range does not match anything, resulting in invalid peer dependencies. Related to yarnpkg/berry#5841.
noahnu added a commit to monoweave/monoweave that referenced this issue Mar 8, 2024
@noahnu
fix: handling of pre-v0.1 when coercing implicit peer dependencies to…
43ce66a 
… minor (#38)

Previously, monoweave would throw an error if coerceImplicitPeerDependency was set to minor and a workspace peer dependency was pre-v0.1. This is because the version 0.0.x would get coerced to 0.0.0 resulting in the SemVer range of ^0.0.0. This range does not match anything, resulting in invalid peer dependencies. Related to yarnpkg/berry#5841.
@oupencti
Copy link

oupencti commented Apr 2, 2024

/opencti# yarn install
➤ YN0000: · Yarn 4.1.1
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed in 0s 719ms
➤ YN0000: ┌ Post-resolution validation
➤ YN0060: │ graphql is listed by your project with version 16.8.1, which doesn't satisfy what graphql-import (p73478) and other dependencies request (^14.0.2 || ^15.0.0).
➤ YN0086: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements for details, where is the six-letter p-prefixed code.
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed in 1s 8ms
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed in 1s 90ms
➤ YN0000: · Done with warnings in 3s 382ms
root@ossfergal:/opencti# yarn explain peer-requirements p73478
We have a problem with graphql, which is provided with version 16.8.1.
It is needed by the following direct dependencies of workspaces in your project:

✘ graphql-import@npm:1.0.2 [5bd70] (via ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ merge-graphql-schemas@npm:1.7.8 [5bd70] (via ^0.11.7 || ^0.13.0 || ^14.0.2 || ^15.0.0)

However, those packages themselves have more dependencies listing graphql as peer dependency:

✘ apollo-utilities@npm:1.3.4 [1a50b] (via ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ apollo-link@npm:1.2.14 [f3e6e] (via ^0.11.3 || ^0.12.3 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ apollo-link-http-common@npm:0.2.16 [f3e6e] (via ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ graphql-tools-fork@npm:9.0.1 [5883f] (via ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0-rc)
✘ @graphql-toolkit/common@npm:0.10.3 [8ad33] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ @graphql-toolkit/graphql-tag-pluck@npm:0.10.3 [8ad33] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ @graphql-toolkit/code-file-loader@npm:0.10.3 [75c79] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ @graphql-toolkit/core@npm:0.10.3 [75c79] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ @graphql-toolkit/graphql-file-loader@npm:0.10.3 [75c79] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ @graphql-toolkit/json-file-loader@npm:0.10.3 [75c79] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ @graphql-toolkit/schema-merging@npm:0.10.3 [75c79] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ @graphql-toolkit/url-loader@npm:0.10.3 [75c79] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0) ✘ apollo-upload-client@npm:13.0.0 [8de27] (via 14 - 15)
✘ @graphql-toolkit/common@npm:0.10.4 [ec2a5] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ graphql-tools@npm:5.0.0 [ec2a5] (via ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ @graphql-toolkit/file-loading@npm:0.10.4 [bd61a] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)
✘ @graphql-toolkit/schema-merging@npm:0.10.4 [bd61a] (via ^0.8.0 || ^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0 || ^15.0.0)

Put together, the final range we computed is ^14.0.2 || ^15.0.0
root@ossfergal:~/opencti# yarn explain peer-requirements p73478

@clemyan clemyan mentioned this issue Apr 4, 2024
Merged
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Rework peer requirement and warning system clemyan/berry
6 participants
@arcanis @noahnu @izifortune @eigilsagafos @MrDockal @oupencti