Currently, guided remediation does not consider peerDependencies when making patches, which can (often?) result in a proposed patch having incompatible peer dependencies, which is a resolution failure in npm.
This is mostly because the deps.dev resolver we use was based on npm version 6, which does not automatically install or verify peerDependencies. Currently, we use the --legacy-peer-deps flag to ignore the problems found in modern npm versions. Ideally the resolver should evaluate peers, since we're possibly missing some vulnerabilities from implicitly included. Though this needs a change on the deps.dev side of things.
Still, we'd need to detect and fix issues in patches affecting peerDependencies. This probably requires a step after resolution to check for peerDependencies among the direct dependencies, and update the peer package if the version constraints are not correctly satisfied, and re-resolve.
Currently, guided remediation does not consider peerDependencies when making patches, which can (often?) result in a proposed patch having incompatible peer dependencies, which is a resolution failure in npm.
This is mostly because the deps.dev resolver we use was based on npm version 6, which does not automatically install or verify peerDependencies. Currently, we use the
--legacy-peer-deps
flag to ignore the problems found in modern npm versions. Ideally the resolver should evaluate peers, since we're possibly missing some vulnerabilities from implicitly included. Though this needs a change on the deps.dev side of things.Still, we'd need to detect and fix issues in patches affecting peerDependencies. This probably requires a step after resolution to check for peerDependencies among the direct dependencies, and update the peer package if the version constraints are not correctly satisfied, and re-resolve.