dependencieslisted

# Dependencies Patterns Domain expertise for dependency management and security analysis. Use alongside `devflow:review-methodology` for complete dependency reviews. ## Iron Law > **EVERY DEPENDENCY IS AN ATTACK SURFACE** > > Each package you add is code you didn't write but must trust. Minimize dependencies. > Pin versions. Audit regularly. A single compromised transitive dependency can compromise > your entire application. "It's a popular package" is not a security review. --- ## Dependency Categories ### 1. Security Vulnerabilities Known CVEs, vulnerable version ranges, malicious packages. **Violation**: Wide version range includes vulnerable versions ```json { "lodash": "^4.0.0" } // Includes vulnerable 4.17.0-4.17.20 ``` **Correct**: Pin to safe version ```json { "lodash": "^4.17.21" } // First safe version ``` ### 2. Version Management Unpinned versions, missing lockfiles, dependency conflicts. **Violation**: Unpinned allows any version ```json { "express": "*", "lodash": "latest" } ``` **Correct**: Pin with lockfile ```json { "express": "^4.18.2" } // + committed lockfile ``` ### 3. Dependency Health Outdated packages, unused dependencies, unnecessary heavy packages. **Violation**: Heavy dependency for simple task ```json { "moment": "^2.29.4" } // 300KB for date formatting ``` **Correct**: Use native or lighter alternative ```typescript new Date().toLocaleDateString(); // Native ``` ### 4. License Issues Incompatible licenses (GPL in MIT projec