Composer Include Files Laravel Package

Product Decisions This Supports

This package supports a narrow bootstrap-ordering decision: ensuring selected PHP files load before Composer’s normal autoload files entries. It is relevant when a product depends on a polyfill, function shim, constant/config bootstrap, legacy compatibility layer, or test/development override that must run earlier than Composer’s generated autoload sequence.

PM decisions it can inform:

• Build vs buy: For most products, a one-line application bootstrap require before vendor/autoload.php is simpler, more transparent, and easier to own than adding a Composer plugin. Buy only if the ordering requirement genuinely cannot be expressed in application bootstrap code.
• Legacy roadmap: It can be a tactical unblocker for maintaining an older service while migrating away from global function/class overrides. It should not become a permanent platform convention.
• Dependency integration: It helps evaluate whether a third-party package’s autoload files must be pre-empted or supplemented by application code. Validate the exact ordering requirement with a failing test before adopting.
• Feature scope: It forces the team to distinguish a real product requirement from an architectural smell. “Load before autoload” is often better solved by explicit initialization, service providers, or refactoring dependency boundaries.
• Risk planning: The package is low-signal overall: 125 stars, last release in 2020, and a low opportunity score. Treat it as a compatibility tool with a removal plan, not a default dependency.

When to Consider This Package

Consider it only when all of these are true:

• You have a specific, documented requirement for a file to load before Composer’s generated autoload files entries.
• The requirement cannot be cleanly moved into an explicit application bootstrap step before vendor/autoload.php.
• You are maintaining a legacy or constrained codebase where changing bootstrap order is riskier than adding a plugin.
• You have verified compatibility with your current Composer version, PHP version, deployment process, plugin allow-listing, and CI install flow.
• You accept the maintenance risk of a package last released in 2020 and will pin versions and monitor for Composer/PHP breaks.
• You have tests that assert load order and runtime behavior, plus a rollback plan.
• You have verified source provenance and license because the repository metadata is incomplete in the supplied record.

Look elsewhere or build a small internal bootstrap when:

• You are starting a new product or service. A simple require of an application bootstrap file before vendor/autoload.php is more transparent and avoids plugin execution during Composer install.
• You need class autoloading rather than file inclusion. Composer’s PSR-4/classmap autoloading is the correct tool.
• You need dependency injection, service providers, or framework bootstrapping. Use the framework’s bootstrap/container rather than global include ordering.
• Your organization prohibits Composer plugins or requires maintained dependencies with recent releases and active security response.
• The only goal is to override a function or class from a dependency. Prefer refactoring, explicit adapters, or dependency replacement; global override ordering is fragile.
• You cannot test load-order behavior in CI across supported PHP and Composer versions.

How to Pitch It (Stakeholders)

Executives: This is a small, old Composer plugin that solves a narrow bootstrap-ordering problem. It is not a strategic platform investment, and its age and low adoption signal make it unsuitable as a default dependency. Approve it only as a time-boxed compatibility measure for a legacy system, with a named owner and a removal plan.

Engineering: The package can force configured files to load ahead of Composer’s autoload files, which can unblock legacy shims, polyfills, or configuration bootstraps. But it adds a Composer plugin to the install path and depends on a package last released in 2020. Before adoption, prove the ordering requirement with a failing test, verify Composer 2 plugin allow-listing and CI behavior, and compare against a one-line application bootstrap require before vendor/autoload.php. If we adopt, pin the version, add load-order tests, and schedule removal once the legacy dependency is refactored.