Home Search Pricing Get inErrata About

Sign in Sign up

Graph/build-dependency-drift

Pattern

Build Dependency Drift

build-dependency-drift

Resolved dependencies, transitive artifacts, and tooling versions drift out of sync—so vulnerability scanners still flag old components, Gradle/IDE classloading fails, artifacts can’t be found in expected repositories, and JVM/Kotlin target mismatches break compilation.

Node Details

Public graph metadata

Updated7/14/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.

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.

Bitrise Android release builds fail at `:package_info_plus:compileReleaseJavaWithJavac` with `error: invalid source release: 17`. The same project builds locally in release/development.

Execution failed for task ':app:mergeReleaseJavaResource'. — In the Run Gradlew step in expo. Tension: 2 files found with path 'org/bouncycastle/pqc/crypto/picnic/lowmcL5.bin.properties' from inputs. Outcome: Adding a packaging block may help.

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.

We run `dotnet list .sln package --vulnerable --include-transitive --source https://api.nuget.org/v3/index.json` nightly on our CI server. Tension: update the runtime on our CI server and instruct our customer to do the same on their machines.

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.

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.

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.

Gradle builds the project, but the annotation processor does not run

Could not find org.jetbrains.kotlin:kotlin-stdlib-jdk11:2.2.0. — Execution failed for task ':app:checkDebugAarMetadata'. Tension: Could not resolve all files for configuration ':app:debugRuntimeClasspath'. Outcome: I was attempting to use the `kotlin-stdlib-jdk11` library, version 2.0.20, which does not exist, my build was failing.

I'm upgrading a Vaadin 23.2 app to Vaadin 24.8. I have a compilation error on one of my components. Tension: IntelliJ IDEA doesn't show any error, but Gradle compilation (JDK17) throws. Outcome: when I remove the class the issue is gone.

I can't import some classes from the library — I'm trying to integrate my legacy app (in Java) with a library from a new partner (made with Kotlin). Tension: Android Studio it shows to me in both class finder or suggestion, but when I try to import even with * I get unreferenced class.

Error running 'Main'. Tension: com.android.tools.idea.gradle.dcl.lang.DeclarativeParserDefinition PluginClassLoader. Outcome: com.android.tools.idea.gradle.dcl.lang.DeclarativeParserDefinition PluginClassLoader(plugin=PluginDescriptor(name=Gradle Declarative Support, id=com.android.tools.gradle.dcl, descriptorPath=plugin.xml, path=~/bin/intellij/plugins/android-gradle-declarative-lang-ide, version=251.23774.435, package=null, isBundled=true), packagePrefix=null, state=active, parents=PluginDescriptor(name=Kotlin, id=org.jetbrains.kotlin, descriptorPath=plugin.xml, path=~/bin/intellij/plugins/Kotlin, version=251.23774.435-IJ, package=org.jetbrains.kotlin, isBundled=true), PluginDescriptor(name=Gradle, id=com.intell.

it kicks an error saying it can't find the artifact in the jboss-ga-repository — I added it to my pom the following dependency node from mvnrepository.com. Tension: I don't know how to set that up so that maven will build. Outcome: how can I fix this?

Plugin net.fabricmc:fabric-loom:1.10-SNAPSHOT:20250225.144903-2 requires at least Gradle 8.12. — A problem occurred configuring root project 'projectname'. Tension: This build uses Gradle 8.11.1.

'source.lib/httpclient-5.4.1.jar' build entry is missing — build.properties. Tension: These errors appear even though I added the httpclient-5.4.1.jar, httpcore-5.3.1.jar, slf4j-api.jar, and slf4j-simple.jar to the classpath and configured them. Outcome: Open the Manifest.MF and have a look at the Require-Bundle are the dependencies added there?

After updating to IntelliJ 2024.3 I can longer execute JUnit tests, if they have a maven dependency with a `` tag. — After updating to IntelliJ 2024.3. Tension: this is lost everytime I hit update maven settings. Outcome: If I manually add the jar to the module settings the tests do work again.

Fatal error compiling: error: release version 21 not supported — mvn clean package -Pstaging -e. Outcome: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile.

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.

[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

Build Dependency Drift - inErrata Knowledge Graph | Inerrata