DevStackDaily: Fixing Composer Dependency Conflicts: Downgrading ramsey/uuid and brick/math for Legacy Laravel

The problem: Running composer install or composer update on a legacy Laravel project fails with a dependency resolution error pointing at ramsey/uuid or brick/math — even though you didn't touch either package directly.

Environment: Legacy Laravel (7.x) project on PHP 7.2/7.3, Composer 2.x

The Error

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - ramsey/uuid[4.7.0, ..., 4.7.5] require ext-json * -> the requested PHP extension json is missing from your platform.
    - ramsey/uuid[4.x-dev] requires php ^8.0 -> your php version (7.3.29) does not satisfy that requirement.

brick/math throws a near-identical message — a version requiring PHP 8+ getting pulled in by a dependency chain, even though your project itself targets PHP 7.x.

Why It Happens

You almost never require ramsey/uuid or brick/math directly — they're transitive dependencies, pulled in automatically by something else in your composer.json (commonly through packages like league/* libraries, certain payment SDKs, or newer versions of Laravel packages that quietly bumped their own minimum PHP requirement).

When Composer resolves your dependency tree, it tries to grab the latest compatible version of every package by default. If a newer major version of ramsey/uuid or brick/math requires PHP 8, but your project is still on PHP 7.x, Composer can't satisfy both constraints — and the whole install fails, even though older versions of those same packages would work fine.

The Fix

Explicitly pin both packages to their last PHP 7-compatible major versions in composer.json, so Composer stops trying to pull the newer, incompatible releases:

"require": {
    "ramsey/uuid": "^4.2.3",
    "brick/math": "^0.9.3"
}

These are the last major versions of each package that still support PHP 7.2/7.3 — anything newer in the 4.7+ line (ramsey/uuid) or 0.10+ line (brick/math) requires PHP 8.

Then run:

composer update ramsey/uuid brick/math

Updating just these two packages (instead of a full composer update) avoids accidentally pulling unrelated packages to newer, possibly incompatible versions at the same time.

    
    composer.json
  
  "require": {
-  "ramsey/uuid": "^4.7.0",
-  "brick/math": "^0.10.2",
+  "ramsey/uuid": "^4.2.3",
+  "brick/math": "^0.9.3",
  }

    $ composer update ramsey/uuid brick/math

Step-by-Step

Run composer why ramsey/uuid (and the same for brick/math) to see exactly which package is pulling it in — useful context even after the fix.
Add explicit version constraints for both packages in composer.json, as shown above.
Run composer update ramsey/uuid brick/math — not a full update.
If Composer still complains, check the package identified in step 1 — it may itself need a version pin to stop it from demanding a newer transitive dependency.
Run composer install again to confirm the lock file resolves cleanly.

Pinning older package versions is a workaround, not a permanent fix — it papers over the real issue, which is that the project is stuck on an unsupported PHP version. If upgrading the project to PHP 8+ is on the roadmap at all, that's the fix that actually removes this class of problem permanently, rather than needing a new version pin every time another dependency bumps its PHP requirement.

Got a different Composer resolution error blocking you? Post the exact message on the Contact page.