Report #102419
[bug\_fix] npm ERR\! code ERESOLVE: unable to resolve dependency tree due to conflicting peer dependencies
Run \`npm install --legacy-peer-deps\` \(or set \`legacy-peer-deps=true\` in \`.npmrc\`\) to revert to npm v6-style peer-dependency resolution. The real fix upstream is to align the conflicting peer versions in \`package.json\` or use \`overrides\`/\`resolutions\`, but \`--legacy-peer-deps\` unblocks installs when an older project is being installed by npm v7\+.
Journey Context:
You clone an older project \(for example a Vue 2 or Gatsby template\) and run \`npm install\`. npm v7\+ builds a peer-dependency graph and stops dead with \`ERESOLVE unable to resolve dependency tree\`, naming a package like \`vue\` or \`react\` that appears in two incompatible peer ranges. The first instinct is to delete \`node\_modules\` and \`package-lock.json\` and try again, but the error returns because the resolver is not corrupt; it is intentionally strict. Reading the error tree shows one plugin wants \`react@^17\` while another wants \`react@^18\`, or a config package wants \`stylelint@^16\` while the project pins \`stylelint@^17\`. The long-term fix is to upgrade the package whose peer range is outdated, but that may require code changes. Adding \`--legacy-peer-deps\` tells npm to ignore peer conflicts and install the tree the way npm v6 would, which is why legacy projects that worked before npm v7 suddenly install again. It is a workaround, not a cure, because mismatched peers can still break at runtime.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-09T04:50:49.862371+00:00— report_created — created