Hello Bundle Laravel Package

Technical Evaluation

Architecture fit: None, and the mismatch is structural rather than stylistic. liip/hello-bundle is a Symfony 2 bundle — a Bundle subclass, a DI extension, XML/YAML service definitions, and Symfony routing conventions. Laravel's extension model is service providers, the container, and route files; there is no bundle kernel to register into and no adapter worth writing for a demo scaffold. The brief's framing as a "Laravel/PHP package" is itself a finding: the intake record mislabels the target framework, which is exactly the class of error a TPM's checklist should catch before an engineer spends time on it.

Integration feasibility: Zero as a runtime dependency. The package is explicitly [DEPRECATED] and its repository is archived; it targets Symfony 2.x plus a stack of FriendsOfSymfony bundles that are themselves abandoned. It is a reference application demonstrating bundle structure — not a library with a reusable, versioned API surface. Composer resolution against a modern Laravel app (which pulls Symfony 6.x/7.x components transitively) will fail on constraint conflicts before a single class loads.

Technical risk: Absolute and unbounded relative to benefit. Archived means no maintainer, no CVE response, no PHP 8.x compatibility, and no Composer 2 hygiene. Forcing installation with --ignore-platform-reqs drags abandoned transitive dependencies into the application and produces class-not-found fatals on kernel/bundle registration. The 198 stars are a historical artifact of the Symfony2 era; 0 dependents is the only signal that matters for a product decision. A score of 1.26 is consistent with "not viable."

Key questions:

• Is there a real requirement behind this candidate, or is it placeholder residue in the intake list? If real, what is the underlying job — a smoke-test endpoint, a scaffolding reference, or an auth/REST example?
• Does the scoring model treat archived: true as a hard gate or a weighted input? This package should never reach TPM review, and the fact that it did is a process defect worth closing.
• Who owns the written rejection record, and where does it live so this option does not resurface in three quarters?
• What is the cost of the native equivalent, so the rejection can be framed as "we already have this in ~1 day" rather than "we have nothing"?

Where the TPM leverage actually is: not in adoption, but in three artifacts this package enables — a documented rejection, a canonical tripwire example for the dependency intake checklist, and a calibration reference for what "EOL framework + archived + zero dependents" looks like in practice.

Integration Approach

Stack fit: Misaligned on framework and on era. Symfony 2.x (2011–2017) versus Laravel 10/11/12 on PHP 8.2+. Different container semantics, different HTTP kernel, different autoloading assumptions, and a front-end toolchain (Assetic, Bower) that predates the modern build pipeline entirely.

Migration path: No code migration; there is nothing portable. If the underlying pattern is the actual need — a reference "hello" endpoint for smoke tests or scaffolding conventions — implement it natively: one route in routes/web.php, one invokable controller, one Blade view. Roughly 50 lines, no external dependency, and ownership stays in-house. If teams want it standardized, publish it as an internal Composer package under our namespace and registry where we control the lifecycle.

Compatibility: Non-resolvable. Composer will conflict on symfony/* constraints; bypassing with --ignore-platform-reqs produces a class-not-found failure the first time anything touches Symfony kernel classes. No partial-adoption path exists — there is no "just use the routing part" because the routing part is Symfony routing.

Sequencing:

1. Reject as a runtime dependency and record the rationale in the decision log (framework mismatch, archived, deprecated, EOL baseline, zero dependents).
2. Add an archived / deprecated / framework-generation gate to package intake so these are auto-filtered before scoring and TPM review. Use this package as the worked example in the checklist documentation.
3. If the hello-world scaffold is a genuine need, build it in-house (≤1 day) and publish internally.
4. Re-baseline the candidate queue to confirm no other Symfony2-era or cross-framework packages are sitting in the Laravel backlog — this one is unlikely to be the only mislabel.

Operational Impact

Maintenance: Zero upstream. Archived means no maintainer, no CVE response, no PHP version support. Any fork becomes wholly ours — full ownership cost for no functional return. The TPM-relevant framing: this is not a cheap dependency, it is a permanent internal liability wearing a dependency's clothes.

Support: No active channel, no maintainer, no issue triage. Star count reflects past visibility in the Symfony2 ecosystem, not current viability. Zero dependents confirms there is no production community to lean on for answers or patches.

Scaling: Not applicable — there is no meaningful runtime surface. The only thing this scales is dependency-graph risk and audit surface.

Failure modes: composer install resolution failure; class-not-found on Symfony kernel/bundle classes; container compile errors; autoload collisions with abandoned FOS bundles; and, if an install is ever forced through, silent exposure to unpatched transitive dependencies that will surface as an audit finding rather than an incident — which is worse for a TPM because it lands in compliance review, not the on-call rotation.

Ramp-up: N/A for a Laravel team. Anyone assigned would spend their time proving there is no path rather than building one. Cost to reach a "no" decision: under an hour. Cost to deliver the native equivalent: under a day. Cost of adoption: unbounded and permanent. Recommendation: reject and close. The valuable output of this review is the process fix — archived, deprecated, and cross-framework packages should never consume a TPM review cycle, and this is the example to point at when writing that rule.