Real‑world examples of package dependency not found errors

Real examples of package dependency not found errors in 2024–2025

When people ask for examples of examples of package dependency not found errors, they’re usually not looking for definitions; they want to see the exact messages that break their builds. Let’s start with realistic logs and scenarios from different ecosystems, then unpack what’s going on.

Node.js / npm: Missing transitive dependency during CI

A very common example of a dependency not found problem shows up when a Node.js project works on a developer’s laptop but fails in CI. The log might look like this:

$ npm install
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: web-app@1.4.0
npm ERR! Found: react@18.2.0
npm ERR! node_modules/react
npm ERR!   react@"18.2.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer react@"^17.0.0" from some-react-lib@2.1.0
npm ERR! node_modules/some-react-lib
npm ERR!   some-react-lib@"^2.1.0" from the root project

This isn’t just a version conflict; in older npm versions or stricter CI configs, the conflicting peer dependency can behave like a dependency not found situation, because npm refuses to install a tree it can’t reconcile. On a local machine, a developer might have previously installed a compatible version, so the cache hides the problem.

In 2024, with npm 10 and stricter resolution defaults, these examples of package dependency not found errors show up more often when teams upgrade Node versions in CI images but forget to refresh lockfiles. The fix typically involves:

• Updating the conflicting library to a version that supports the current React
• Or aligning React to a version that matches peer requirements
• Regenerating package-lock.json in a clean environment

Yarn / pnpm: Workspace monorepo can’t find a local package

Monorepos give us some of the best examples of dependency resolution weirdness. Picture a Yarn workspaces setup:

// packages/app/package.json
{
  "name": "app",
  "dependencies": {
    "ui-lib": "^1.2.0"
  }
}

// packages/ui-lib/package.json
{
  "name": "@company/ui-lib",
  "version": "1.2.0"
}

A developer runs yarn dev and sees:

Module not found: Error: Can't resolve 'ui-lib' in '/repo/packages/app/src'

The package exists, but the name doesn’t match. The app depends on ui-lib while the workspace publishes @company/ui-lib. This is a clean example of package dependency not found errors where the underlying cause is simple: the import and the dependency name are wrong, not the installation.

In pnpm, similar issues pop up when package.json lists a workspace dependency, but the pnpm-workspace.yaml doesn’t include that package folder. The registry lookup fails, and you get a ERR_PNPM_FETCH_404 or ERR_PNPM_NO_MATCHING_VERSION message, another entry in the list of real examples.

Python / pip: Version pinning versus disappearing releases

Python’s ecosystem offers very clear examples of dependency not found failures when a pinned version vanishes from PyPI or a private index. A real‑world‑style log:

$ pip install -r requirements.txt
ERROR: Could not find a version that satisfies the requirement requests==2.19.0 (from versions: 2.31.0, 2.32.0, 2.32.1)
ERROR: No matching distribution found for requests==2.19.0

In this scenario, the team is using an internal mirror or an air‑gapped index that only syncs recent releases. The requirements.txt file is old, and the requested version is no longer available. The error text is quite literally an example of package dependency not found errors: pip can’t find a matching distribution.

In 2024–2025, this hits more frequently in:

• Long‑lived enterprise apps that haven’t updated dependencies in years
• Docker images pinned to ancient base images with outdated indexes
• Environments affected by supply chain security efforts that restrict or prune packages

The fix: relax version pins, update dependencies, or point pip to a current index. Tools like Poetry and pip-tools help regenerate constraints so you don’t keep reinstalling ghosts.

Python virtual environments: Installed but not importable

Another subtle example of a dependency not found error: the package is installed globally, but not in the active virtual environment.

$ python -m venv .venv
$ source .venv/bin/activate
$ pip install fastapi
$ python
>>> import uvicorn
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'uvicorn'

The developer installed fastapi but forgot that uvicorn is an extra (fastapi[all]) or a separate dependency. This is a softer example of package dependency not found errors: the runtime can’t import a package that was assumed to be present. In production, the same pattern appears when Dockerfiles install dependencies in one layer but run code in another image without those packages.

Authoritative documentation from the Python community, like the Python Packaging User Guide, strongly recommends virtual environments and pinned dependencies to reduce these surprises.

Java / Maven: Artifact not found in internal repository

Java build tools offer textbook examples of dependency resolution failures. A typical Maven error looks like this:

[ERROR] Failed to execute goal on project billing-service:
Could not resolve dependencies for project com.company:billing-service:jar:1.0.0:
Could not find artifact com.company:shared-lib:jar:2.3.1 in internal-repo (https://nexus.company.com/repository/maven-releases/)

This is one of the best examples of a dependency not found error in enterprise settings. The artifact shared-lib:2.3.1 either:

• Was never published to the internal Nexus/Artifactory server
• Was removed during a cleanup task
• Lives only in a developer’s local ~/.m2/repository cache

Locally, mvn package succeeds because the dependency exists in the developer’s cache. In CI or in a new container, the cache is empty, and you get a clean, reproducible example of package dependency not found errors.

Gradle shows similar messages:

Could not resolve all files for configuration ':compileClasspath'.
> Could not find com.company:shared-lib:2.3.1.
  Searched in the following locations:
      https://repo.maven.apache.org/maven2/
      https://nexus.company.com/repository/maven-releases/

The fix is less about Gradle or Maven and more about your artifact lifecycle: publish the missing version, bump to an existing one, or adjust repository configuration.

.NET / NuGet: Package removed or source misconfigured

In .NET projects, NuGet produces very recognizable examples of dependency not found problems. A build might fail with:

NU1101: Unable to find package Company.Common.Logging. No packages exist with this id in source(s): nuget.org, CompanyFeed

Common triggers include:

• Renaming a package but forgetting to update csproj references
• Migrating from packages.config to PackageReference and losing a feed
• Private feeds requiring authentication in CI but not locally

This is a clear example of package dependency not found errors where the package name is correct historically, but the current feeds don’t serve it anymore. The .NET docs on NuGet package sources walk through how to configure sources so these errors are easier to diagnose.

Front‑end bundlers: Module not found at build time

Modern front‑end stacks (Webpack, Vite, esbuild, Next.js) give us highly visible examples include messages like:

Module not found: Error: Can't resolve 'lodash-es' in '/app/src/components'

This usually happens when:

• The import uses lodash-es, but package.json only has lodash
• The package is listed in devDependencies and isn’t installed in a production build
• A monorepo build step runs in a subfolder without access to the root node_modules

These are front‑end flavored examples of package dependency not found errors where the bundler is simply surfacing what Node’s module resolution can’t locate. The fix is often as boring as installing the right package or correcting the import path.

Containers and CI: Works on my machine, fails in the pipeline

If you want the best examples of dependency not found bugs that waste entire sprints, look at Docker and CI logs.

Scenario: A Python microservice builds fine locally but fails in GitHub Actions.

Step 6/9 : RUN pip install -r requirements.txt
...
ERROR: Could not find a version that satisfies the requirement psycopg2==2.7.3.2
ERROR: No matching distribution found for psycopg2==2.7.3.2

Locally, the developer is on python:3.9, while the CI image quietly moved to python:3.12. That older psycopg2 version doesn’t ship wheels for 3.12, so pip can’t find a compatible build. This is a more subtle example of package dependency not found errors: the package exists, but not for that platform/runtime combo.

You’ll see the same pattern with Node images when native modules don’t have prebuilt binaries for a newer Node version. The fix is to:

• Align local and CI base images
• Update packages to versions that support the newer runtime
• Or pin the runtime until dependencies catch up

Organizations focused on software supply chain security (see NIST’s secure software development guidance) increasingly enforce reproducible builds, which makes these discrepancies easier to detect but more visible when they break.

Package registries and network issues: The invisible dependency

Not every example of a dependency not found error is your fault. Sometimes the registry is down or blocked.

Common logs:

npm ERR! 404 Not Found - GET https://registry.npmjs.org/some-internal-lib - Not found

or

ERROR: Could not find a version that satisfies the requirement internal-lib (from versions: none)
ERROR: No matching distribution found for internal-lib

Behind corporate firewalls, DNS misconfigurations or proxy issues can turn a perfectly valid package into a fake dependency not found situation. Developers often chase version ghosts when the real problem is that the registry URL is unreachable from CI or production.

These real examples highlight why observability around builds matters. Logging, caching, and clear registry configuration reduce the guesswork.

Patterns behind these examples of package dependency not found errors

Looking across these examples of examples of package dependency not found errors, some clear patterns emerge:

• Name mismatches: ui-lib vs @company/ui-lib, lodash vs lodash-es, renamed NuGet packages.
• Version drift: Old pins (requests==2.19.0, psycopg2==2.7.3.2) against newer runtimes or curated indexes.
• Environment mismatch: Local caches, different base images, missing virtual environments.
• Repository configuration: Missing or misconfigured Maven/NuGet/npm/pip sources.
• Transitive dependencies: Peer dependency conflicts and nested packages that never get installed.

Treat these best examples as a checklist when you debug:

• Verify the exact package name in the registry.
• Confirm the version exists for your runtime and platform.
• Compare local vs CI configuration: Node/Python/Java versions, base images, feeds.
• Clear caches and reinstall in a clean environment to remove local artifacts from the equation.

FAQ: common questions and short examples

What are some quick examples of dependency not found errors across languages?

Some quick, real examples include:

• ModuleNotFoundError: No module named 'uvicorn' in Python when the package isn’t installed in the active virtual environment.
• Module not found: Can't resolve 'lodash-es' in a React app using Webpack or Vite.
• Could not find artifact com.company:shared-lib:jar:2.3.1 in a Maven build.
• NU1101: Unable to find package Company.Common.Logging in a .NET build using NuGet.
• npm ERR! 404 Not Found - GET https://registry.npmjs.org/internal-lib in Node.js when a private registry is misconfigured.

Each one is an example of the same underlying theme: the tool can’t map your declared dependency to an actual, installable artifact.

How can I prevent these examples of errors from recurring?

You won’t eliminate them entirely, but you can reduce the frequency:

• Standardize runtimes and base images across local and CI.
• Use lockfiles and constraint files, and refresh them on runtime upgrades.
• Regularly audit and update dependencies instead of letting them age indefinitely.
• Document and centralize registry and feed configuration for npm, pip, Maven, Gradle, and NuGet.

These practices turn scary examples of package dependency not found errors into rare, predictable maintenance tasks instead of weekly fire drills.