Path Composer Plugin Lib Laravel Package

Product Decisions This Supports

• Build vs. buy for internal Composer tooling. If your platform or developer-experience team is writing one or more Composer plugins that need to redirect, normalize, or resolve install paths (custom vendor-dir, monorepo layouts, shared dependency directories), this library replaces reimplementing Composer's internal path resolution and event wiring. That is a real engineering-hours trade, even if the package itself is tiny.
• Standardizing monorepo / multi-app install layouts. Teams running several Laravel/PHP apps out of one repository, or sharing a single vendor tree across services, can use a path-aware plugin to enforce a consistent install contract instead of ad-hoc composer.json overrides per project.
• Exposing vendor_dir / base_dir as constants. Downstream tooling (custom autoloaders, deployment scripts, container entrypoints, static analysis configs) can consume deterministic path constants rather than guessing at relative paths — useful for reproducible builds and CI.
• Reducing bespoke glue in internal plugin scaffolds. If your org maintains a template for Composer plugins, this serves as a lightweight, MIT-licensed base layer, which is cheaper to standardize on than maintaining your own fork of Composer internals.
• Not a fit for the typical Laravel product roadmap. This is infrastructure for people who build Composer plugins; it does not affect application features, so it should be evaluated under platform/DX budget, not product feature budget.

When to Consider This Package

Adopt (or, more realistically, evaluate as a reference implementation) when all of the following hold:

• You are authoring a Composer plugin, not just consuming one. Application developers, Laravel package authors, and CI-only users have no use for this.
• Your plugin genuinely needs path resolution/normalization or install-path customization — i.e., you would otherwise be reading Composer's PluginInterface, EventSubscriberInterface, and installer internals yourself.
• You are comfortable pinning a version and treating the source as something you could vendor or fork, because the maintenance signals are weak: 1 GitHub star, 0 dependents, no visible community. A single-maintainer, near-zero-adoption library is a supply-chain and bus-factor consideration, not a stability guarantee.
• The MIT license and small surface area matter to you — the blast radius of a fork is low, which is the main thing that makes this acceptable despite its immaturity.

Look elsewhere — or simply copy the relevant helpers into your own codebase — when:

• You are building a standard Laravel application or a distributable Laravel package. Wrong layer entirely.
• You need a supported, versioned API with a changelog and issue triage. This package does not offer that.
• Your path requirements are one-off and simple (a single "vendor-dir" entry in composer.json). Config is cheaper than a dependency.
• You have a policy against pulling in dependencies with no dependents and minimal maintenance history. In that case, an internal ~200-line utility module is the safer call and costs about the same.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a free, MIT-licensed micro-library that helps our platform engineers build Composer plugins — the tooling that controls where PHP dependencies get installed. It is not a customer-facing component and carries no licensing cost. Its strategic value is small but real: it saves engineering time on internal build tooling and standardizes how we lay out dependencies across repositories. The main risk is maturity — it is a one-maintainer project with essentially no adoption — so any use should be time-boxed, pinned, and trivially reversible by copying the code in-house.

For engineering leadership: Treat this as a build-vs-buy data point, not a platform commitment. If the DX team is writing more than one path-manipulating Composer plugin, this library removes duplicated knowledge of Composer internals and gives us vendor_dir/base_dir constants for deployment and autoload tooling. Because it is tiny, MIT, and unmaintained, the recommended posture is evaluate-and-vendor: read the source, pull the useful helpers into our own plugin scaffold, and keep the upstream dependency optional. We should not make it a load-bearing dependency in shipped customer code, and we should not spend roadmap capacity on it — it belongs in the platform/DX backlog as a low-effort, low-priority enablement item.