Home Search Pricing Get inErrata About

Sign in Sign up

Graph/dependency-version-drift

Pattern

Dependency Version Drift

dependency-version-drift

A recurring dependency version drift where mismatched transitive library versions lead to inconsistent runtime or test behavior, and the primary remediation is comparing/aligning installed Jest packages to restore deterministic behavior.

Node Details

Public graph metadata

Updated4/30/2026

Connections

30 linked nodes

The user tries to mock a Zustand store (state values and actions) in a Jest test file but fails to override the store used by the React component. As a result, the component does not receive the mocked state/action implementations.

npm fails to install react-hook-form because its peer dependency on React does not match the project’s installed React version (React 19 RC).

Type instantiation is excessively deep and possibly infinite — in a monorepo/workspace project. Tension: on seemingly benign types like this. Outcome: I've found this is almost always due to a mismatched dependency between 2 packages in your repository.

When publishing the Vite-built package, the generated dist output includes internal build artifacts such as node_modules/_virtual and/or breaks dependency resolution because subpath imports like react/jsx-runtime aren’t treated as externals. This results in unwanted contents being packaged and incorrect bundling for NPM publication.

I'm facing challenges with resolving shared dependencies and ensuring that binaries are correctly executed — I'm working on a monorepo setup using `pnpm` workspaces to manage multiple related projects. Tension: I want to maintain a set of common dependencies that can be used across different projects without listing them in every single `package.json`. Outcome: You cannot share dependencies like this.

NestJS hot reload does not pick up changes in referenced workspace packages

Webpack has trouble bundling the shared library when imports resolve as "../shared/..."

it keeps installing 4.2.0 — `latest` is specified in my package.json. Tension: 4.4.0 has been out for 18 days. Outcome: If I specify `"checkly": "4.4.0",`, then it will install 4.4.0.

TypeError: Cannot redefine property:'someTest' — jest spyOn not working on index file, cannot redefine property. Tension: these solutions don't work. Outcome: compare the previous version and find out the lib version(@jest/console, @jest/core, @jest/environment, etc.) in `node_modules` has been changed.

ERROR Unknown option: 'legacy-peer-deps' — pnpm install --legacy-peer-deps. Tension: Did you mean 'strict-peer-dependencies'?

Updating `gesto` in the root project's `node_modules` only affects the top-level dependency, but `react-infinite-viewer` (via `infinite-viewer`) still installs and uses its own nested `gesto`, resulting in multiple versions/edits being present.

Linting and checking validity of types .Debug Failure. No error for last overload signature — after pnpm build. Tension: ELIFECYCLE Command failed with exit code 1.

Trying to apply pnpm patching to a package that is not directly listed in the project’s dependencies but is brought in transitively by another dependency.

Jest failing to import these libraries in a dependent library — I am currently trying just `tsc` and `es2020` modules. Tension: private (not published) Typescript libraries in a monorepo be built so they can be shared amongst other libraries and apps (both Node and browser) in the repo? Outcome: You build all the packages together in one step.

During `pnpm install`, the library fails due to unresolved peer dependencies coming from its dependencies, even though the library itself does not use those peer dependencies.

VSCode does not seem to read the nested dependencies' types — One of the app's dependencies (specified in its package.json) is `react-router-dom` and `react-router-dom` has `react-router` as a dependency. Tension: When I use the `useLocation` hook, VSCode displays its type as. Outcome: it seems that it is able to follow pnpm's symlinks and read `useNavigate` hook's type.

I don't know if they have separate repositories or if they both use the same repository. — I'm considering using Yarn or PNPM instead of NPM. Tension: if they use separate repositories, then I should be worried about some packages being available in NPM repository, but absent in other repositories. Outcome: The answer is no.

Switching a project from pnpm back to npm is needed due to tool compatibility issues, without reverting a previous commit/push.

Zone mismatch. — during runApp. Tension: The Flutter bindings were initialized in a different zone than is now being used. Outcome: This will likely cause confusion and bugs as any zone-specific configurat.

It finds some changes in `/dist/index.js.map` file after running `npm run package` — update my GitHub action to use latest version of "base" action. Tension: one PR check fails on checking if `/dist` directory was updated.

Inconsistent JVM-target compatibility detected for tasks 'compileDebugJavaWithJavac' (1.8) and 'compileDebugKotlin' (17). Tension: Execution failed for task ':stripe_android:compileDebugKotlin'. Outcome: BUILD FAILED in 14s.

npm fails with ERESOLVE due to conflicting peer dependencies: the project uses @mantine/core@6.x while @mantine/rte@5.10.5 requires @mantine/core@5.10.5. Additional peer conflicts exist (e.g., react version mismatch for react-jutsu).

The issue with cyclonedx-node-yarn I have is that I'll have to run different packages for different technologies and them merge them into one SBOM. — The repository also contains generated documentation with some JS files. And contains some helper scripts. Tension: It was just much slower then rest of the options there.

this dependency has 2 critical vulnurabilities — org.eclipse.jetty jetty-websocket 8.1.1.v20120215. Tension: there are no correspondng version of `jetty-websocket` so I have no idea how can I fix this issue. Outcome: Those vulnerabilities are fixed in jetty-server » 9.3.24.v20180605.

In a large npm codebase, polyfill.io usage is hard to detect reliably because simple greps and manual network inspection can miss dynamically loaded polyfills or subdependencies.

Dependabot flagged this issue but cannot update webpack-dev-middleware to a non-vulnerable version. Tension: updating to a secure version seems non-trivial.

Adding nondeterministic compilation breaks reproducible builds — users will no longer be able to verify the packages they install. Tension: this security measure is a good example of so-called security theater. Outcome: it will not provide additional security for most of the cases, but will greatly complicate a lot of things.

you are going to get a change request — if you don't keep your front-end dependencies up-to-date after a year or two. Tension: that will require you to upgrade an existing dependency for compatibility, that will break 5 other things. Outcome: you won't be able to modify them without declaring package.json bankruptcy and starting over.

An attacker finds a vulnerability in one of your frontend-dependencies which he is able to exploit somehow — the backend stack is highly secure. Tension: malicious behavior which effects your highly secure backend-application. Outcome: keep your front end packages up-to-date.

The project’s dependency tree includes the vulnerable `inflight@1.0.6` library (deduped) via transitive dependencies of Angular build/CLI tooling, and the user needs to mitigate the vulnerability without migrating to Angular 16.

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

© 2026 Inerrata

Dependency Version Drift - inErrata Knowledge Graph | Inerrata