Dependency Resolver

Analyze, manage, and resolve software dependencies to ensure safe and successful deployments. Identifies conflicts, security vulnerabilities, version mismatches, and missing dependencies.

Core Capabilities

1. Dependency Analysis

Examine project dependencies:

• Direct dependencies - Packages explicitly required
• Transitive dependencies - Dependencies of dependencies
• Dev dependencies - Development-only packages
• Peer dependencies - Required by packages but not auto-installed
• Optional dependencies - Non-critical packages

2. Conflict Detection

Identify dependency issues:

• Version conflicts - Multiple versions of same package
• Missing dependencies - Required but not installed
• Incompatible versions - Version constraints that can't be satisfied
• Circular dependencies - Packages depending on each other
• Platform incompatibility - OS or architecture mismatches

3. Security Auditing

Check for vulnerabilities:

• Known CVEs - Common Vulnerabilities and Exposures
• Outdated packages - Old versions with security patches available
• Malicious packages - Typosquatting or compromised packages
• License issues - Incompatible or restrictive licenses

4. Dependency Resolution

Provide solutions:

• Version pinning - Lock compatible versions
• Conflict resolution - Strategies to resolve version conflicts
• Dependency updates - Safe upgrade paths
• Alternative packages - Replacement suggestions
• Minimal installations - Remove unnecessary dependencies

Dependency Resolution Workflow

Step 1: Identify Package Manager

Detect which dependency system is in use:

Package manager files:

npm/yarn:     package.json, package-lock.json, yarn.lock
pip:          requirements.txt, Pipfile, setup.py, pyproject.toml
maven:        pom.xml
gradle:       build.gradle, build.gradle.kts
cargo:        Cargo.toml, Cargo.lock
go:           go.mod, go.sum
composer:     composer.json, composer.lock
bundler:      Gemfile, Gemfile.lock
nuget:        *.csproj, packages.config

Step 2: Parse Dependency Manifest

Read and understand dependency declarations:

npm (package.json):

{
  "dependencies": {
    "express": "^4.18.0",
    "lodash": "~4.17.21"
  },
  "devDependencies": {
    "jest": "^29.0.0"
  },
  "peerDependencies": {
    "react": ">=16.0.0"
  }
}

Python (requirements.txt):

django>=4.0,<5.0
requests==2.28.1
numpy>=1.20.0
pytest  # No version specified

Maven (pom.xml):

<dependencies>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>5.3.23</version>
  </dependency>
</dependencies>

Step 3: Analyze Dependency Tree

Build complete dependency graph:

my-app
├── express@4.18.2
│   ├── body-parser@1.20.1
│   │   └── bytes@3.1.2
│   ├── cookie@0.5.0
│   └── debug@2.6.9
│       └── ms@2.0.0
└── lodash@4.17.21

Check for:

• Multiple versions of same package
• Deeply nested dependencies
• Large dependency trees
• Unmaintained packages

Step 4: Detect Issues

Identify problems:

Version conflicts:

app requires:
  - package-a@1.0.0 (depends on shared@^1.0.0)
  - package-b@2.0.0 (depends on shared@^2.0.0)

Conflict: shared@1.x vs shared@2.x

Missing dependencies:

Error: Cannot find module 'missing-package'
Cause: Listed in package.json but not installed

Security vulnerabilities:

lodash@4.17.20 has known vulnerability CVE-2020-8203
Severity: High
Fix available: Upgrade to lodash@4.17.21

Step 5: Propose Solutions

Recommend fixes:

For version conflicts:

• Use compatible versions
• Update conflicting packages
• Use resolutions/overrides
• Consider alternatives

For missing dependencies:

• Install missing packages
• Add to manifest file
• Check for typos

For security issues:

• Update vulnerable packages
• Apply security patches
• Replace with secure alternatives

Dependency Management Patterns

Pattern 1: Version Conflict Resolution

Issue:

// package.json
{
  "dependencies": {
    "package-a": "^1.0.0",  // requires lodash@^3.0.0
    "package-b": "^2.0.0"   // requires lodash@^4.0.0
  }
}

Analysis:

Dependency tree:
├── package-a@1.0.0
│   └── lodash@3.10.1
└── package-b@2.0.0
    └── lodash@4.17.21

Conflict: Two versions of lodash (3.10.1 and 4.17.21)

Solution 1: Update package-a

{
  "dependencies": {
    "package-a": "^2.0.0",  // Updated version uses lodash@^4.0.0
    "package-b": "^2.0.0"
  }
}

Solution 2: Use resolutions (npm/yarn)

{
  "dependencies": {
    "package-a": "^1.0.0",
    "package-b": "^2.0.0"
  },
  "resolutions": {
    "lodash": "^4.17.21"
  }
}

Solution 3: Find alternative

{
  "dependencies": {
    "alternative-package-a": "^1.0.0",  // Doesn't depend on lodash
    "package-b": "^2.0.0"
  }
}

Pattern 2: Security Vulnerability Fix

Audit result:

$ npm audit

found 3 vulnerabilities (1 moderate, 2 high)

High: Prototype Pollution
Package: lodash
Dependency of: express
Path: express > lodash
More info: https://npmjs.com/advisories/1065

Solution:

# Check if update fixes it
npm audit fix

# Force update if needed
npm audit fix --force

# Or manually update
npm install lodash@latest

Verify fix:

npm audit
# 0 vulnerabilities

Pattern 3: Missing Peer Dependency

Error:

npm WARN package-b@1.0.0 requires a peer of react@>=16.0.0 but none is installed.

Analysis:

// package-b requires react but doesn't install it
{
  "peerDependencies": {
    "react": ">=16.0.0"
  }
}

Solution:

npm install react@^18.0.0

Update package.json:

{
  "dependencies": {
    "react": "^18.0.0",
    "package-b": "^1.0.0"
  }
}

Pattern 4: Outdated Dependencies

Check for updates:

npm outdated

Package    Current  Wanted  Latest  Location
express    4.17.1   4.18.2  4.18.2  my-app
lodash     4.17.20  4.17.21 4.17.21 my-app
react      17.0.2   17.0.2  18.2.0  my-app

Analysis:

• Current: Installed version
• Wanted: Max version satisfying semver
• Latest: Newest version available

Solution strategy:

# Safe: Update to wanted versions
npm update

# Major updates (breaking changes)
npm install react@latest  # Review changelog first

# Pin specific version
npm install express@4.18.2 --save-exact

Pattern 5: Circular Dependencies

Detection:

Circular dependency detected:
  package-a → package-b → package-c → package-a

Analysis:

// package-a/index.js
const b = require('./package-b');

// package-b/index.js
const c = require('./package-c');

// package-c/index.js
const a = require('./package-a');  // Circular!

Solution:

// Restructure to break cycle
// 1. Extract shared code to new package
// 2. Use dependency injection
// 3. Lazy loading

// Option 1: Extract shared functionality
// package-shared/index.js
module.exports = { sharedFunction };

// package-a/index.js
const shared = require('./package-shared');

// package-c/index.js
const shared = require('./package-shared');

Pattern 6: Platform-Specific Dependencies

Issue:

{
  "dependencies": {
    "fsevents": "^2.3.2"  // macOS only
  }
}

Error on Linux:

npm ERR! notsup Unsupported platform for fsevents@2.3.2

Solution:

{
  "dependencies": {
    "chokidar": "^3.5.3"  // Cross-platform alternative
  },
  "optionalDependencies": {
    "fsevents": "^2.3.2"  // macOS optimization
  }
}

Pattern 7: Dependency Bloat

Analysis:

# Check installed package sizes
npm ls --all --depth=0
du -sh node_modules/

# Result: 500MB for small app!

Identify large packages:

npx cost-of-modules

┌────────────────────────┬───────────┬────────────┐
│ name                   │