Composer Json Manipulator Laravel Package

Product Decisions This Supports

• Build vs. buy for release automation. The package answers a narrow question: do we hand-roll composer.json editing in our tooling, or take a dependency? Its scope is load → merge → mutate → save, which is exactly the "glue" layer in a monorepo split-and-publish pipeline (merging package-level manifests into a root manifest, injecting replace entries when splitting a monorepo into standalone packages, bumping version constraints across sub-packages).
• Monorepo → multi-package distribution roadmap. If the roadmap includes "publish each module as its own Composer package," this library is a candidate building block for the automated step that rewrites manifests at release time. It supports the decision to automate that step rather than doing it by hand in a release checklist.
• Packaging/scaffolding product surface. Any CLI or generator we ship that emits a Laravel package skeleton, meta-package, or plugin bundle needs deterministic composer.json authoring. This evaluates whether that capability is a dependency or ~100 lines of internal code.
• CI/CD investment. Informs whether release engineering time goes into a custom manifest-mutation script (owned, testable, tuned to our conventions) versus a third-party utility (faster to start, externally governed).
• Risk posture on dependencies. The adoption signals here — no visible stars, zero dependents, a score of 0, and an opportunity score in the mid-40s — are themselves a product decision input: it argues against making this a load-bearing dependency in anything customer-facing.

When to Consider This Package

Consider it when:

• You are already inside the Symplify ecosystem (e.g., monorepo-builder) and this is a transitive piece rather than a new commitment.
• You need only a handful of operations — merge two manifests, add/remove a key, save — and want formatting and key ordering preserved rather than a naive json_encode rewrite.
• You are prototyping release tooling and want to defer the "write our own" decision by a sprint.

Look elsewhere when:

• Composer's own CLI can do the job: composer require, composer config, composer remove are officially maintained, respect lock files, and are far safer than post-hoc file surgery. Most "we need to edit composer.json" requirements collapse into this.
• You need the underlying primitive rather than a wrapper: Composer ships Composer\Json\JsonManipulator and JsonFile, which preserve formatting and are maintained by the Composer team. If this package is largely a thin convenience layer over that, the honest build-vs-buy answer is "use the upstream class directly."
• The project has a long support horizon. Zero dependents and no star traction mean no community backstop; Symplify's package portfolio has been consolidating over recent years, so plan for the maintainer-abandonment scenario and assume you may own a fork.
• The manifest mutation is part of a customer-facing or security-sensitive path. Untracked dependencies writing to build inputs deserve extra scrutiny, and a small internal helper with tests is cheaper to audit.

Recommendation: treat as a reference implementation, not a dependency. Read its API surface, then reimplement the 2–3 operations you actually need on top of Composer's JsonManipulator, or drive changes through the Composer CLI.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a tiny utility for programmatically editing composer.json files — the plumbing behind automated package releases. It is free, MIT-licensed, and would save a small amount of engineering time. It is also effectively unmaintained by adoption metrics: no dependents, no community traction, and a vendor whose package portfolio is contracting. My recommendation is not to adopt it as a dependency, but to use it as a blueprint and build the ~1 day of internal code it represents. Net effect: same capability, no new supply-chain or maintenance risk, negligible cost delta.

To engineering (the substance): Scope is load/merge/save with formatting preservation. The genuinely useful parts are almost certainly available upstream in Composer's JsonManipulator/JsonFile, so adopting this adds an indirection layer we'd have to maintain ourselves the moment it goes quiet. Proposed path: (1) confirm our requirements are limited to merge + key mutation; (2) prefer composer CLI commands in CI where a lock file is involved; (3) fall back to a small internal ComposerJsonMutator with unit tests for the pure-merge cases. That gives us ownership, testability, and no external abandonment risk.

Decision requested: approve the internal-helper approach over adding the dependency; revisit only if we standardize on Symplify's monorepo-builder, in which case this comes along for free.