ActiveManage Docs
← Back to activemanage.co.uk

Dependencies

Managing Dependencies

Dependencies are the third-party libraries (Composer packages, npm packages, system tools) the platform relies on. Managing them well means stability, security and a clean upgrade path.

Dependencies dashboard showing rows: package name, current version, latest version, security status (clean/CVE outstanding), license, last updated; with filters for outdated, vulnerable, abandoned

Where Dependencies Live

  • composer.json: PHP runtime libraries.
  • package.json: JavaScript front-end libraries.
  • System packages: ImageMagick, FFmpeg, Tesseract, Redis etc. — installed via the OS package manager.
  • Database extensions: InnoDB, JSON, FTS.
  • External services: Stripe, SendGrid, AWS — managed as account credentials.

What to Watch

  • Security advisories: CVE-tracked vulnerabilities — patch quickly.
  • End-of-life: Major versions reaching EOL — plan migration.
  • Abandoned packages: No commits in 2+ years — find replacement.
  • License compatibility: GPL/AGPL packages in commercial product may need legal review.
  • Major version upgrades: Breaking changes require code adjustment.

Worked Examples

  • Security patch: A CVE published for an upstream library; CI flags it; PR with updated version reviewed and merged within hours.
  • Major upgrade: PHP 8.2 → 8.4 over the course of a sprint, with feature flags allowing rollback if needed.
  • Abandoned package: A used library hasn't been updated in 3 years; fork it or replace with maintained equivalent.
  • License audit: Annual review confirms all dependencies are MIT/Apache/BSD — no GPL contamination in the commercial codebase.

Updating Dependencies Safely

Updating dependencies is essential — but reckless updates introduce regressions. A systematic process keeps you patched without making your nights longer.

Dependency update process diagram: 1. Identify update (CVE / minor / major), 2. Read changelog, 3. Update on a branch, 4. Run CI tests, 5. Deploy to staging, 6. Smoke test, 7. Production deploy with monitoring

Process by Update Type

  • Security patch: Fast — confirm the patch addresses the CVE, run full CI, deploy to staging for hours not days, then production.
  • Minor / patch version: Routine — CI tests are typically enough; deploy with regular release cadence.
  • Major version: Careful — read the changelog end-to-end, identify breaking changes, allocate sprint time for code updates, test exhaustively, deploy with monitoring and a rollback plan.

Tooling

  • Composer outdated / npm outdated: Show what's out of date.
  • Composer audit / npm audit: Show known vulnerabilities.
  • Dependabot / Renovate: Automated PRs for updates.
  • Snyk / GitHub Advanced Security: Continuous scanning for new CVEs.

Safety Practices

  • Pin to exact versions in lock files. Never run with floating dependencies in production.
  • Update one major dependency at a time so causes of failures are clear.
  • Have a working rollback (containers, blue/green) within minutes.
  • Run the full integration test suite, not just unit tests.
  • Tag each release; can revert by re-deploying the previous tag if needed.

Worked Examples

  • Critical CVE in Composer package: Patch found, branch created, CI run, staged within 2 hours, production same day.
  • Routine npm update: Weekly Dependabot PR with 15 minor updates; CI passes; merged with no further fuss.
  • PHP major upgrade: 8.2 → 8.4 with feature flag; canaried on 5% traffic for a day; fully ramped after no errors observed.
  • Failed upgrade: One npm package had a regression; lock file reverted; staged again with that package pinned.