Composer Installer Laravel Package

Product Decisions This Supports

• Modular monolith vs. package sprawl. A Composer installer that routes packages into modules/ and themes/ instead of vendor/ is an architectural commitment: it lets the product ship first-party capability as separately versioned packages without abandoning a single deployable application. This release makes that commitment safe to rely on.
• Build vs. buy on module scaffolding. Teams weighing a custom in-house installer against this package now have a lower-risk answer: the package has collision detection against the working tree, a 32-test suite, and CI running Pint and Pest. "Adopt and extend" becomes defensible where previously "write our own" was the safer call.
• Roadmap confidence for module/theme marketplaces. Collision detection is the primitive that makes third-party or customer-supplied modules viable. If the roadmap includes extension distribution, this defect fix is a prerequisite, not a nice-to-have.
• Release and upgrade policy. The rename behaviour change forces rm -rf of the old target before reinstall. That is a documented, intentional upgrade step — a product decision to trade convenience for protection against silently orphaning a directory. Support docs, upgrade guides, and internal onboarding need to reflect it.
• Deployment and CI investment. The extra.plugin-modifies-install-path flag removes a class of "unexplained churn in tracked package directories" that would otherwise consume engineering time in every pipeline that vendors or commits modules/ and themes/. That is a recurring cost removed, not a one-off fix.
• Trust signal for due diligence. The package previously had four known section 6.1 defects, no tests, and no CI. It now has all three addressed. Any decision gated on "is this dependency maintained and verified?" can be revisited.

When to Consider This Package

Consider it when:

• The application is a Laravel monolith that intends to organise first-party features as installable packages under modules/ or themes/, and you want Composer to manage them like any other dependency.
• You need Composer installs to be deterministic in CI and in environments where vendor/-relative path assumptions break — the plugin-modifies-install-path flag exists precisely because Composer's defaults mislead here.
• Multiple people or pipelines write to the same working tree, making the new collision detection (a target directory whose composer.json names a different package fails the install) genuinely load-bearing.
• You are willing to accept the rename workflow: changing a package's Composer name while keeping its install directory requires removing the old target first.
• You want a small, single-purpose installer rather than a full modularity framework, and you are comfortable that the maintained surface is this narrow.

Look elsewhere when:

• Packages must live in vendor/ and you have no need for modules//themes/ placement — the plugin adds a behavioural layer you will not use.
• You need capability-based Composer integration. Plugin no longer implements Composer\Plugin\Capable; any consumer that relied on that interface, even with an empty getCapabilities(), must be updated.
• You require an installer with a long public release history and broad third-party adoption. This is the first release with a test suite and CI, so the track record is one release deep.
• Your process cannot tolerate a hard failure on directory collision — for example, tooling that reuses a fixed install path across package renames without cleanup. The new check will block those installs by design.
• You depend on LiberuInstaller being constructible only with no arguments in a way that assumes a fixed root. The constructor now takes an optional root directory defaulting to the working directory; behaviour is unchanged, but any subclass or reflection-based wiring should be checked.

How to Pitch It (Stakeholders)

For executives: This release converts a known-fragile internal dependency into a verified one. Four previously logged defects are fixed, the package gains its first automated test suite — 32 tests — and continuous integration. The practical effect is fewer mysterious changes in tracked module and theme directories, and installs that refuse to overwrite a different package's directory rather than doing so silently. There is one deliberate behaviour change: renaming a package now requires deleting its old directory first, which is a short, documented step. Net position: same scope, materially lower operational risk.

For engineering: The installer now declares extra.plugin-modifies-install-path so Composer activates it before it computes install paths, which ends the vendor/-assumption churn. Collision detection inspects the working tree rather than only the current process, and correctly treats an absent, unreadable, or nameless composer.json as no evidence of ownership. LiberuInstaller takes an optional root directory, defaulting to the working directory — behaviour is identical, but path logic is now injectable and tested. Plugin drops the unused Composer\Plugin\Capable implementation and its empty getCapabilities(). Coverage spans path computation, supported package types, name validation, traversal and absolute-path rejection, and both collision paths, enforced by Pint and Pest in CI.

For support and platform teams: The one user-visible change is the rename path — remove the old target, then install. That failure is intentional and is the mechanism that catches an unremoved directory. Update upgrade guides and onboarding checklists accordingly; no other migration work is required.