Home Search Pricing Get inErrata About

Sign in Sign up

Graph/transitive-dependency-version-conflict

AntiPattern

Dependency Version Conflicts

transitive-dependency-version-conflict

Conflicting transitive dependency versions get locked into the build, causing tooling and runtime to disagree (OS-specific builds, stale front-end deps, webpack-dev-server/vue-cli ranges), which then surfaces as collectstatic errors, vulnerability-driven constraints, or framework warnings tied to outdated libs.

Node Details

Public graph metadata

Updated6/28/2026

Connections

30 linked nodes

MATCHESSolution

Try running — npm config set legacy-peer-deps true. Tension: npm ERR! ERESOLVE unable to resolve dependency tree. Outcome: npm config set legacy-peer-deps true.

MATCHESSolution

Install circular-dependency-plugin for webpack to make debugging easier

MATCHESSolution

Aligning the package versions usually fixes the issue — between 2 packages in your repository. Tension: a different version of the "zod" dependency. Outcome: either manually or by using a tool like ncu. You can also move common dependencies into your root package to enforce a common version.

MATCHESSolution

Install the required dependencies explicitly in each app (and optionally share versions via pnpm dependency catalogs) or otherwise manage shared versions using pnpm catalogs rather than expecting a workspace package with peerDependencies to fully eliminate per-app installs.

MATCHESSolution

If you need consistency between `node_modules` and `pnpm-lock.yaml`. Tension: especially in workspaces or deployments.

MATCHESSolution

different versions of devcontainer's OS lead to different versions of compiled dependencies — When I migrate another Apps, I might need another Debian version. Tension: this would lead to the packages land in the sam. Outcome: I figured out later.

MATCHESSolution

webpack config. Tension: These two solutions can both fix this issue.

MATCHESSolution

The reliable workaround was to unify React versions across the entire monorepo so that shared and all apps use the same React version, eliminating the type incompatibility.

MATCHESSolution

Outcome: strict-peer-dependencies=false.

MATCHESSolution

Add `"canvas": "*"` to `optionalDependencies` in `package.json` — I'm only using `pdf.js` in the browser. Tension: There may have also an issue/incompatibility with `pdf-js` version `^3.9.179`. Outcome: Update `pdfds-dist` to latest version (currently `v3.10.111`).

MATCHESSolution

You can tell pnpm to always use a specific version of a package. — You can add a `pnpmfile.js` at the root of your project. Tension: overriding the version specified in its `package.json`. Outcome: packageJson.dependencies.prisma = '^4.15.0';.

MATCHESSolution

{ "pnpm": { "peerDependencyRules": { "ignoreMissing": ["typescript"] } } }. Tension: however for this small project i am not using typescript. Outcome: I just need to add this in my package json to remove the warning.

MATCHESSolution

multiple dependencies in a project require esbuild. Tension: separate dependencies require different versions of esbuild.

MATCHESSolution

I had to update it — Turns out I had some settings in the monorepo's app's `tsconfig` wrong. Tension: VSCode does not seem to read the nested dependencies' types. Outcome: To work properly, I had to update it:.

MATCHESSolution

Set packageManager in package.json to a supported tool with a version range, such as "^pnpm@6.32.4" or "^yarn@1.22.19"

MATCHESSolution

"pnpm": { "onlyBuiltDependencies": ["esbuild", "onnxruntime-node", "sharp", "protobufjs"] }. Tension: proves the binding + model load, and doubles as the cache-populating step if you actions/cache the model directory.

MATCHESSolution

Remove the conflicting packages and reinstall matching versions: uninstall @mantine/core/@mantine/rte/@mantine/hooks (and react-jutsu) and then install @mantine/core@5.10.5, @mantine/rte@5.10.5, and @mantine/hooks@5.10.5. Also downgrade React (or adjust dependencies) to satisfy react-jutsu peer dependency requirements.

MATCHESSolution

An alternative might be to use Paket. — NuGet uses a pessimistic version resolution strategy. Tension: This should give you more up-to-date transitive package versions. Outcome: the lock file should prevent unwanted updates.

MATCHESSolution

best practices for configuring devServer or devMiddleware — in future setups. Tension: prevent such vulnerabilities. Outcome: without upgrading the entire Vue CLI or webpack stack.

MATCHESSolution

fixed version for the vulnerability starts from 5.3.4. Tension: updating to a secure version seems non-trivial. Outcome: cannot update webpack-dev-middleware to a non-vulnerable version.

MATCHESSolution

Update the `ip` dependency to a fixed version (`ip` 1.1.9 or 2.0.1+), merge Dependabot’s PR, or force the version via `npm update` or `package.json` `overrides`.

MATCHESSolution

keep your front end packages up-to-date — This mostly assumes web frontend, but can also potentially be applicable to other front ends. Tension: you won't be able to modify them without declaring package.json bankruptcy.

MATCHESSolution

it will be fixed by the developer of the dependency when they know about the issue — one of your frontend-dependencies. Tension: for now the attacker can read/export the JWT of your user. Outcome: updated to the latest version where this issue was fixed by the developer of the dependency.

MATCHESSolution

recommendations for alternative open-source tools that can check for dependency vulnerabilities — dependency vulnerabilities.

MATCHESSolution

Identify the exact transitive dependency introducing each vulnerable artifact (e.g., inspect the Maven dependency tree), upgrade or exclude/override those specific transitive versions, and re-run the scan. Use tools like Vulert playground (or similar dependency vulnerability checkers) to confirm which dependencies in the POM cause the findings and what they pull in.

MATCHESSolution

Use npm’s dependency override mechanism to force a safe version of `glob` (e.g., by adding an `overrides` entry such as `"glob": "^9.0.0"`), which in turn removes/updates the transitive `inflight` version.

MATCHESSolution

Tension: so a bad NPM module that recently got updated, doesn't end up making your app compromised.

MATCHESSolution

Use `bower list` to enumerate installed Bower packages and then manually compare versions against known vulnerabilities. Prefer migrating away from Bower (e.g., to Yarn or npm) and then run the corresponding audit tools there; tools like `bower-away` can help with the migration.

MATCHESSolution

Update the xml2js dependency to a non-vulnerable version (e.g., replace 0.4.23 with 0.5.0 in package-lock.json) and run npm install to ensure the patched version is used.

MATCHESSolution

Align all Spring Boot/Spring Security/Authorization Server dependency versions (e.g., upgrade the Spring Boot plugin to the same version and remove hardcoded version overrides), and prefer using org.springframework.boot:spring-boot-starter-oauth2-authorization-server so transitive dependencies match.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata