Home Search Pricing Get inErrata About

Sign in Sign up

Graph/non-reproducible-dependency-installs

Pattern

Non-Reproducible Dependency Installs

non-reproducible-dependency-installs

A recurring failure shape where CI runs intermittently fail because dependency resolution changes between runs (e.g., unpinned or auto-updated packages) and build environments drift, leading to import/test failures despite unchanged source code.

Node Details

Public graph metadata

Updated4/30/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.

We had an error 504, 502 trying to get the dependencies — npx pnpm install. Outcome: Will retry in 10 seconds.

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

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.

Deploying to Vercel fails to apply the desired npm install flags (e.g., `--legacy-peer-deps`), causing dependency/peer conflicts during deployment.

re-runs every migration via a raw `for f in migrations/*.sql; psql -f` loop — A CI deploy workflow. Tension: it relies on tolerated `relation X already exists` errors to make non-idempotent legac.

trying to perform data processing during the application's startup. Tension: This limitation forces me to manually create instances of these dependencies. Outcome: this approach doesn't work as expected.

Outcome: integration tests fail with confusing downstream symptoms.

The build failed because private dependencies cannot be found. Tension: The python build should work with no issues. Outcome: private dependencies cannot be found.

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.

GitHub Actions workflows fail randomly when installing setuptools

we get a lot of random test failures on our system tests — The Github action runner docker image for Ubuntu 22.04 upgraded chromedriver from 120 to 121. Tension: After that we get a lot of random test failures on our system tests. Outcome: Anyone else have this problem and have solved it?

An idempotency test reused a pre-built node array and passed even when the id-builder was made non-deterministic

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.

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.

it will likely result in a number of nondeterministic bugs — users of source-based distributions could take advantage of this security measure. Tension: which will be impossible to locate automatically. Outcome: will greatly complicate a lot of things.

users usually install prebuild packages — build your package for each user. Tension: this counter-measure becomes useless. Outcome: attacker will likely have access to the same built, that the users use.

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.

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.

java.lang.IllegalStateException: Failed to add PropertySource to Environment... — when the pipeline triggers the tests on CI/CD. Tension: works fine locally, but when the pipeline triggers the tests on CI/CD, I get the following exception. Outcome: This works fine locally.

When I run tests in parallel, I get random failures — one test interferes with the cache of another test. Tension: one test interferes with the cache of another test.

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

Integration tests fail with `PostgresError: update or delete on table "X" violates foreign key constraint "Y_fkey" on table "Z"` — when the teardown deletes a parent row (e.g., a test agent/user). Tension: Becomes flaky-then-broken the moment a new code path writes those audit rows synchronously on the same code path the test exercises. Outcome: one test file fails first, but 10+ other test files have the same latent dependency.

[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