Installer Laravel Package

Technical Evaluation

Architecture fit pug/installer is a Composer-level utility, not a runtime library. Its purpose is narrow: it teaches Composer how to place packages that declare a custom install type (the Pug extension/plugin convention used by the pug-php ecosystem). It therefore earns a place in the architecture only if the application (a) renders views through Pug rather than Blade, and (b) consumes third-party Pug extensions distributed as Composer packages of that custom type. In a conventional Laravel stack — Blade, Eloquent, standard service providers — the fit is effectively nil; adding it buys no templating capability on its own. It belongs in the dependency-resolution layer, so its blast radius is the build, not the request path.

Integration feasibility Mechanically trivial: a composer require plus an allow-plugins entry under config (mandatory since Composer 2.2). The real feasibility question is compatibility, not effort. A 2020-vintage Composer plugin may declare a composer-plugin-api constraint that predates Composer 2.3+; if so, install hard-fails until the constraint is widened, which requires a fork since there is no upstream. Secondary checks: PHP version constraint (^8.0/^8.1 may be absent), whether the plugin writes only inside vendor/ or also into application paths, and whether the custom type string it supports still matches what current extension packages declare.

Technical risk High, driven almost entirely by abandonment rather than complexity. Last release 2020-10-31, 2 stars, 0 dependents, single-maintainer ecosystem. That means no CVE response path, no Composer API maintenance, and no one to ask when installs start failing. Composer plugins execute in-process with the privileges of the build agent, so every plugin is a supply-chain decision; an unmaintained plugin is an unmonitored one. Mitigating factors: the surface is small (a Composer Installer subclass — likely a few hundred lines at most), MIT-licensed, and removable without touching application code, since extension registration can be done explicitly at runtime.

Key questions

• Do we actually need Pug at all, or is this speculative interest in an alternative view engine? Is there an existing Pug template inventory and toolchain worth preserving?
• Which, if any, of our dependencies declare the custom install type this plugin handles? If the answer is "none," the package has no function in our graph.
• Does its composer-plugin-api constraint permit our pinned Composer version, and does it run clean on PHP 8.1/8.2/8.3 without deprecation noise?
• Does the plugin write outside vendor/? Where does it compute install paths, and can those collide with application directories?
• Who would own an internal fork if we adopt it, and is the MIT license sufficient for that (it is, but ownership still needs a name)?
• Can CI run with --no-plugins and still boot the app? If yes, the plugin is optional and should be treated as such.

Integration Approach

Stack fit Laravel 9–11 on PHP 8.1+ with Blade as the primary engine. Pug would be an additional view engine reached through pug-php/pug and a Laravel bridge (or a custom ViewEngineResolver entry). Note that the bridge packages carry the same 2020-era maintenance profile — adopting Pug is adopting a small, thinly maintained corner of the ecosystem, not a single package decision.

Migration path

• Greenfield: do not add pug/installer. If Pug is mandated, register extensions explicitly — a config array or service-provider method calling the Pug engine's extension API — which is deterministic, reviewable, and free of install-time code execution.
• Brownfield (something already depends on it): replace the plugin with a composer.json extra block plus a post-autoload-dump script that enumerates extensions from installed packages. Same outcome, explicit list, no third-party plugin in the build.
• If the plugin is genuinely required: fork under an internal namespace, widen composer-plugin-api to ^2.0, add a PHP ^8.1 constraint, pin a tag, and vendor or path-repository it.

Compatibility Gate adoption on: plugin-API constraint vs. our Composer version, PHP constraint vs. our runtime matrix, and a composer install run in a clean container with allow-plugins unset (to observe the interactive prompt) and with --no-plugins (to confirm the app still boots). Both results go in the ADR.

Sequencing

1. Inventory which installed packages declare a custom type matching this installer; if zero, close the evaluation.
2. If non-zero, determine whether those extensions are used at runtime or are transitive noise.
3. Verify install behavior on the target PHP/Composer matrix in an isolated branch.
4. If adopted, fork-and-pin before it ever reaches main; do not depend on the public package directly.
5. Canary through one deploy cycle behind allow-plugins scoped by name, never with a blanket true.
6. Record the decision and the fallback (explicit registration) in an ADR so the next owner is not reverse-engineering it.

Operational Impact

Maintenance Effectively unmaintained. There is no upstream fix path, so every future break — a Composer release, a PHP deprecation, a changed type string — becomes internal work. The compensating factor is size: an internal fork is a small, one-time cost, but it still needs a named owner and a place in the dependency-review queue. Without that, it becomes silent drift that surfaces as a failed deploy months later.

Support No community to lean on: ~0 dependents, negligible issue traffic, no maintainer responsiveness to assume. Internal expertise is the only support channel, and the surrounding Pug documentation is sparse enough that onboarding cost sits in the ecosystem, not the package.

Scaling Negligible. It executes once per Composer invocation, has no per-request or per-worker footprint, and does not interact with horizontal scaling, caching, or queue behavior. The only scaling-adjacent concern is CI: plugin prompts in non-interactive environments can hang builds, and plugin execution adds a step to every cold build in the pipeline.

Failure modes

• Hard install failure when the plugin-API constraint no longer matches the Composer version — blocks all deploys, not just Pug ones.
• Silent no-op if the custom type string changes upstream, so extensions land in an unexpected path and Pug renders with missing filters rather than erroring.
• Interactive allow-plugins prompt in CI causing a hung or timed-out build.
• Path collisions if the installer computes destinations outside vendor/.
• Install-time arbitrary code execution in build agents — the reason this is a security-review item, not just a dependency item.
• Deprecation notices under strict CI error handling turning a green build red on a PHP upgrade.

Ramp-up Near-zero for the package itself; it is a minimal utility with one obvious responsibility. The real ramp-up is the Pug ecosystem: engine configuration, extension authoring, and the Laravel bridge, all thinly documented and none of it current. Budget a half-day spike to answer the key questions above and a short ADR either way.

Recommendation: do not adopt. With 2 stars, 0 dependents, no release since 2020, and no function outside a Pug-based view layer, the expected value is negative against any nonzero maintenance cost. Treat it as a signal that the broader pug-php stack is a buy-vs-build decision, not a package-selection one; if Pug is genuinely required, adopt the engine and bridge directly and handle extension registration in application code you control.