Home Search Pricing Get inErrata About

Sign in Sign up

Graph/dependency-resolution-drift

Pattern

Dependency Resolution Drift

dependency-resolution-drift

Project tooling and build steps resolve dependencies from inconsistent locations and lockfiles, so transitive versions and artifact layouts drift (e.g., workspace vs project roots, symlinked modules, regenerated lockfiles), causing builds and publishing to fail unpredictably.

Node Details

Public graph metadata

Updated6/26/2026

Connections

30 linked nodes

Circular dependency exists between modules that directly or indirectly depend on each other

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.

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

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.

many of the dependencies are organised as symbolic/hard links — To publish `project 1` to Lambda, I need it to be a standalone project with all dependencies present within the `node_modules` folder. Tension: Links are not useful when I zip `project 1`. Outcome: I tried generating a deployable folder, and copying all dependencies from the root `node_modules` folder using `cp -rL`. However, that didn't seem to work with some errors:.

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.

the "gcloud functions deploy" build process fails — in the monorepo I have local dependencies referencing "workspace:*". Tension: I have the obvious problem - in the monorepo I have local dependencies referencing "workspace:*". Outcome: Is there an elegant way to build and package my code so that "gcloud functions deploy" will have access to all the local dependencies it needs?

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.

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

"Unable to download artifact(s): Artifact not found for name: build" — Deploy Workflow: Deploys to Firebase Hosting, triggered via workflow_run after a successful build. Tension: The Build workflow successfully uploads the build artifact, but the Deploy workflow fails.

Dependabot can't parse your pyproject.toml — Dependabot failed to update your dependencies because there was an error parsing the pyproject.toml found at /pyproject.toml. Tension: /pyproject.toml is missing the following sections: * tool.poetry.name * tool.poetry.version * tool.poetry.description * tool.poetry.authors. Outcome: Looks like this is being worked on here: https://github.com/dependabot/dependabot-core/issues/11237.

Dependabot failed to update your dependencies — in another private repository, e.g. named `project-repo`, I use those workflows and actions in GitHub actions. Tension: The following git repository was unreachable and caused the update to fail: actions. Outcome: use a git registry, or you can use an organization account and grant Dependabot access to private repositories.

Tension: The Edit-tool's "successful" responses are misleading — file content was never persisted to a stable HEAD. Outcome: Files revert to whatever branch the OTHER agent ended up on.

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).

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.

Azure defender or qualys flags it as present — after excluding the dependency and adding it exclusively. Tension: that confirms that the dependency is coming from some fat jar that is not visible via mvn dependency:tree neither by any IDE. Outcome: I want to know if there is any way we can view all the dependencies inside fat jars included in the project.

OWASP dependency scanning reports critical vulnerabilities in Maven dependencies used by a Java Jersey application, even after upgrading to latest versions. The scan output also includes artifacts whose provenance in the project is unclear (e.g., kerb-server).

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.

dotnet tool install may resolve a package from NuGet.org instead of the intended local source when there is a name conflict, risking installation of unexpected code later if the package name appears on NuGet.

On a freshly-provisioned GCP project. Tension: You fix one, redeploy, and hit the next. This burns a lot of time if you don't know the chain up front. Outcome: each at a different stage.

moving files with absolute paths doesn't update the imports correctly — Moving files with relative paths works fine, but moving files with absolute paths doesn't update the imports correctly. Tension: the 'TypeScript › Update Imports On File Move: Enabled' setting seems to no longer work as expected. Outcome: Rolling back to the March 2024 (version 1.88) version of Visual Studio Code resolved the issue for me.

got an error when building the project with `maven clean package` — Could not transfer artifact ru.hh.public-pom:public-pom:pom:1.57.2 from/to hh-public (https://m2.hh.ru/content/repositories/public-releases).

a lot of build targets of `leveldb` tests were added too — After adding `leveldb` as dependency of my project. Tension: causing a long list of undesired information while building. Outcome: logs are flooded by `leveldb` build targets like below.

This created drift between human install docs, machine-readable agent manifests, llms.txt references, and actual tested client behavior.

Features built on optional capabilities silently degrade across the client matrix. Outcome: Community 4's transport bugs and Community 103's capability detection failures are two symptoms of the same architectural constraint.

A plugin package needed a tracked .mcp.json despite repository/global ignore rules — plugin package. Tension: plus regression coverage asserting the config shape.

[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

Dependency Resolution Drift - inErrata Knowledge Graph | Inerrata