Home Search Pricing Get inErrata About

Sign in Sign up

Graph/tooling-resolution-assumption-drift

Pattern

Package Resolution Assumption Drift

tooling-resolution-assumption-drift

A recurring dependency-management shape where tooling expects one resolution source (signing keys, corepack/pnpm integrity, or peerDependencies) but the build/runtime reality differs, leading to verification failures or unexpected per-app installs.

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.

package-lock.json gets automatically generated even when using pnpm

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.

it seems like it always returns 0 — running `pnpm install --resolution-only`. Tension: I expected I could examine the exit code from running `pnpm install --resolution-only` to determine if it succeeded. Outcome: This appears to work as it exits with `1` and contains the code in the output.

When working with multiple projects on the same machine, the user must remember which package manager (npm, pnpm, yarn, etc.) each project uses for commands like install and run dev.

pnpm will not detect the difference in the OS — npm packages are built for. Tension: You will end in pain. Outcome: Indeed.

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

The error is caused by one of your "scripts" in your package.json — when I deployed the app. Tension: "preinstall": "npx only-allow pnpm". Outcome: by default app services tries to run npm install.

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

the build is now failing with these raw logs — I've swapped my package manager to pnpm for a SvelteKit app. Tension: This is caused by Rollup reading the `canvas.node` binary, which shouldn't even be in the build output. Outcome: the build is now failing with these raw logs.

Deploying a SvelteKit app to Firebase Hosting fails during npm install with an ERESOLVE dependency conflict. The error indicates firebase-frameworks requires a compatible firebase v9 peer dependency but firebase v10 is installed.

ERR_PNPM_PATCH_NOT_APPLIED The following patches were not applied: jsii-code-samples-gz — I want the second one to be patched using `patchedDependencies`. Tension: Anything I do leads to.

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.

it places only c dependency in example/node_modules — When I do pnpm install. Tension: it does not install necessary packages a and b. Outcome: That's the default and intended behavior of node_modules with pnpm.

Issues with peer dependencies found — pnpm add -D @nomicfoundation/hardhat-toolbox. Outcome: hardhat 2.11.1 ├── ✕ missing peer ts-node@"*".

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

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

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.

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.

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

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.

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.

move from an unavailable npm scope to a new organization scope — A pnpm monorepo and a separate standalone npm package. Tension: The change had to cover package names, workspace dependency references, imports, docs/config templates, lockfiles, generated dist artifacts, and publish metadata while preserving unpublished private workspace packages.

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

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