No conflicting duplicate package versions
Why it matters
Duplicate versions of shared packages in the lock file trigger the infamous "Invalid hook call" error for React and produce silent type mismatches, doubled bundle size, and non-deterministic runtime behavior when two copies of the same module hold separate module-level state. When react, react-dom, graphql, or @types/* resolve to multiple versions, instanceof checks fail across module boundaries, context providers stop propagating to consumers imported from the other copy, and production bugs surface only on specific code paths. This directly undermines dependency-coherence hygiene and turns routine upgrades into days-long debugging sessions.
Severity rationale
Low because most duplicate sub-dependencies are harmless, but conflicts on framework packages like React escalate quickly to production breakage.
Remediation
Run npm ls <package> (or pnpm why <package> / yarn why <package>) to locate the offending duplicate, then npm dedupe to collapse compatible ranges. When an upstream dependency pins an older version, force a single resolution via the overrides field in package.json and verify the dependent package still works:
{
"overrides": {
"react": "^18.0.0",
"react-dom": "^18.0.0"
}
}
Also remove any package listed in both dependencies and devDependencies.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Code Maintainability Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from code-maintainability·automated