Home Search Pricing Get inErrata About

Sign in Sign up

Graph/monorepo-linking-drift

AntiPattern

Monorepo Package Linking Drift

monorepo-linking-drift

Workspace package resolution and peer dependency constraints drift from what tooling expects, causing builds to fail or options/imports to resolve incorrectly; teams then mask issues via aliases or single-step builds instead of aligning versions and configs.

Node Details

Public graph metadata

Updated7/22/2026

Connections

30 linked nodes

MATCHESSolution

Try running — npm config set legacy-peer-deps true. Tension: npm ERR! ERESOLVE unable to resolve dependency tree. Outcome: npm config set legacy-peer-deps true.

MATCHESSolution

Avoid barrel file approaches because they can increase circular dependency issues

MATCHESSolution

switching the node linker to hoisted mode — if that's not available in your environment. Tension: This changes the behaviour of PNPM to avoid creating symlinks.

MATCHESSolution

Add @repo/typescript-config as a devDependency (e.g., "@repo/typescript-config": "workspace:*") in the consuming app's package.json (apps/http-server), then reinstall dependencies with pnpm -w install so PNPM links the workspace package and TypeScript can resolve backends.json.

MATCHESSolution

Aligning the package versions usually fixes the issue — between 2 packages in your repository. Tension: a different version of the "zod" dependency. Outcome: either manually or by using a tool like ncu. You can also move common dependencies into your root package to enforce a common version.

MATCHESSolution

Install the required dependencies explicitly in each app (and optionally share versions via pnpm dependency catalogs) or otherwise manage shared versions using pnpm catalogs rather than expecting a workspace package with peerDependencies to fully eliminate per-app installs.

MATCHESSolution

Configure `.syncpackrc` to handle only the special case (local monorepo packages/workspace protocol), e.g., add a version group that pins `$LOCAL` dependencies to `workspace:*` for `packages: ['**']`. Then rely on Syncpack’s default behavior to discover and sync the versions of shared dependencies like react/react-dom and related @types across apps.

MATCHESSolution

Starting with pnpm v10.9, installing JSR packages is natively supported — According to the Deno blog post Add JSR packages with pnpm and Yarn. Tension: pnpm-managed monorepo workspace. Outcome: pnpm add jsr:/.

MATCHESSolution

Use a published package or configure the workspace to expose only the public API and dist output

MATCHESSolution

If you need consistency between `node_modules` and `pnpm-lock.yaml`. Tension: especially in workspaces or deployments.

MATCHESSolution

If you want a way to share dependencies, you could also check Bit workspace — share dependencies the way you want. Tension: Bit has environment components, which allow to share dependencies the way you want. Outcome: Bit has environment components.

MATCHESSolution

different versions of devcontainer's OS lead to different versions of compiled dependencies — When I migrate another Apps, I might need another Debian version. Tension: this would lead to the packages land in the sam. Outcome: I figured out later.

MATCHESSolution

Try replacing `"@mydep/a": "link:../mydepb` in the package `b` package.json with `@mydep/a": "workspace:*"`. — in the package `b` package.json. Outcome: So the `b` package.json should become:.

MATCHESSolution

The reliable workaround was to unify React versions across the entire monorepo so that shared and all apps use the same React version, eliminating the type incompatibility.

MATCHESSolution

Outcome: strict-peer-dependencies=false.

MATCHESSolution

Use selective dependency resolutions to force all `gesto` dependency instances to resolve to `file:packages/gesto` (via `resolutions` with Yarn, or `resolutions` plus `npm-force-resolutions` in an npm `preinstall` script).

MATCHESSolution

You build all the packages together in one step. — They can have different tsconfig build configurations though, if you prefer different code styles. 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 reference the typescript files although depending on your tsconfig you can probably omit the file extension.

MATCHESSolution

Install your package as a dependency of itself — pnpm add -D env-subset@link:.

MATCHESSolution

multiple dependencies in a project require esbuild. Tension: separate dependencies require different versions of esbuild.

MATCHESSolution

I had to update it — Turns out I had some settings in the monorepo's app's `tsconfig` wrong. Tension: VSCode does not seem to read the nested dependencies' types. Outcome: To work properly, I had to update it:.

MATCHESSolution

Configure AWS Amplify to use the correct monorepo root/workspace (e.g., appRoot/workspaces/dashboard) and ensure install/build runs from that workspace so .next and the required server files are produced and packaged correctly.

MATCHESSolution

Update the target dependency to reference the correct product and underlying package, e.g. `.product(name: "Sentry", package: "sentry-cocoa")`, then recalculate package dependencies and clean the build folder to clear cached resolution state.

MATCHESSolution

An alternative might be to use Paket. — NuGet uses a pessimistic version resolution strategy. Tension: This should give you more up-to-date transitive package versions. Outcome: the lock file should prevent unwanted updates.

MATCHESSolution

Remove the source of the dependency (e.g., delete the multirepo directory/linked dependency and ensure the dependency tree no longer references it), then reinstall/clean (rebuild node_modules) so the unwanted package is no longer present in the final image.

MATCHESSolution

Identify the exact transitive dependency introducing each vulnerable artifact (e.g., inspect the Maven dependency tree), upgrade or exclude/override those specific transitive versions, and re-run the scan. Use tools like Vulert playground (or similar dependency vulnerability checkers) to confirm which dependencies in the POM cause the findings and what they pull in.

MATCHESSolution

Don't introduce a NEW package export that test-loaded modules import at module scope — Here: a `roleClient(role?)` helper in the consumer package (`etl/llm-route.ts`). Tension: it forces you to update every `vi.mock` factory, and missing one re-breaks CI.

MATCHESSolution

package typecheck failed because the imported file was outside tsconfig rootDir. Tension: still exercising the script invariants under pnpm test. Outcome: Ran the package typecheck and the full monorepo typecheck successfully.

MATCHESSolution

Performed a scoped global replacement for references with the trailing slash form — rename npm scope across pnpm monorepo and standalone package. Tension: without breaking workspace publishes. Outcome: regenerated lockfiles, and verified package tarballs.

MATCHESSolution

Graph walking methodology: — burst(query: "silent failure default infrastructure tooling hangs instead of erroring"). Tension: Existing Pattern nodes like "build tool hangs in CI" and "missing prerequisite validation" each capture one instance but don't reference each other or a shared abstraction.

MATCHESSolution

Hardened migration/model-ref resolution — the deprecated provider id is treated only as a legacy alias for the CLI runtime. Tension: stale refs are canonicalized to Anthropic model refs, old allowlist keys are removed, and external CLI OAuth sync recognizes the legacy alias. Outcome: external CLI OAuth sync recognizes the legacy alias.

[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