Composer Include Files Laravel Package

Product Decisions This Supports

• Pre-autoload bootstrap requirement — Determines whether your product needs code executed before Composer's autoloader runs (function polyfills, monkey-patches, global helpers, environment shims). If yes, this package is a candidate primitive for that feature.
• Build-vs-buy for bootstrap hygiene — Compares three options: (a) adopt this plugin, (b) add a manual require in public/index.php / artisan / phpunit bootstrap, (c) vendored 40-line Composer plugin maintained in-house. Decision hinges on how many entry points you have and whether you need it to work for dependents of your package, not just your own app.
• Roadmap gating for library/SDK development — If you ship a package that must work on hosts where a function or constant doesn't exist yet, preloading order becomes a product constraint. This package lets your library own the load order rather than asking consumers to edit their bootstrap.
• Legacy migration sequencing — Supports incremental strangler-fig migrations where old global functions must exist before the new autoloaded classes reference them at compile/parse time.
• Test-environment determinism — A consistent include-order guarantee across CI, Docker, and local dev is a feature-quality concern; a plugin that pins order in composer.json reduces "works on my machine" bug reports.
• Not recommended for: general dependency management, performance tuning, or anything where the answer is "just refactor to lazy-load."

When to Consider This Package

Adopt only when all of these are true:

• You have a hard, proven ordering requirement — a file whose side effects must land before any Composer files autoload entry. Confirm this by reproducing a failure that a normal files entry does not fix.
• You control the root composer.json of the consuming app, and you're comfortable that the plugin must be installed as a project-level (not transitive) dependency for predictable behavior.
• You can vendor or fork it. With 12 stars, zero dependents, and a 0.15 score, treat the upstream as abandoned. Pin the commit, copy the source into your repo or your own private Packagist, and own it.
• You've audited the plugin's Composer event hooks (pre-autoload-dump / post-autoload-dump) against your Composer version, including Composer 2.x plugin-API allowlisting (allow-plugins).
• The alternative — a two-line require at the top of each entry point — genuinely does not scale for your situation (many entry points, or the ordering must travel with a distributed package).

Look elsewhere when:

• A plain "autoload": { "files": [...] } entry solves it — which it usually does.
• You only have one or two entry points. A manual require is more transparent and zero-risk.
• You need this to work for downstream consumers of your library. Depending on an obscure Composer plugin transitively is a support burden you will regret; ship a documented bootstrap snippet instead.
• Your team forbids Composer plugins, or allow-plugins is locked down in CI for supply-chain reasons. A 12-star plugin with no maintainer trail is a supply-chain finding waiting to be written up.
• You actually want PSR-4 autoloading or classmap optimization; this package addresses none of that.
• You need PHP 8.x / Composer 2.6+ guarantees and cannot verify the plugin supports them — assume untested until you've run the suite yourself.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, single-purpose build tool, not a product dependency. It solves one narrow problem — making sure a handful of PHP files load before the standard autoloader — which only matters if we hit a specific class of bootstrapping failure. It has essentially no adoption (12 stars, zero downstream packages), so we should treat it as a reference implementation, not a supplier: if we confirm we need the behavior, we should copy roughly a hundred lines into our codebase and own it. Recommendation: no procurement, no vendor relationship, no license cost (MIT), minimal engineering cost if the requirement is real — and no action at all if it isn't.

For engineering leads: Use this as a checklist, not a dependency. First, reproduce the ordering bug with a standard files autoload entry; if that fails, evaluate the plugin's approach in a spike branch. If the approach works, vendor it — pin the commit, add a wrapper test that asserts include order, and document why the ordering exists. Do not add it as a transitive dependency of any package we publish. Budget roughly half a day for the spike and a day for vendoring plus tests, and be explicit that we now own a Composer plugin's compatibility with future Composer releases.

Signal to report upward: low maturity, low adoption, non-trivial blast radius if it breaks silently during composer install in CI. The risk isn't in adopting it; the risk is in adopting it casually.