Http Kernel Bundle Laravel Package

Product Decisions This Supports

• Nothing on an active roadmap. This package is explicitly marked DEPRECATED, is archived, has zero dependents, three GitHub stars, and its last release was March 2020. It cannot inform a build-vs-buy decision because it is not a viable build material.
• Legacy archaeology, not product strategy. The only decision it legitimately supports is: "Does our current or inherited codebase already depend on this?" If yes, that's a migration-planning decision (budget for replacing it), not a feature decision.
• Historical reference for HttpKernel customization patterns. A PM might allow a limited engineering spike (a few hours, timeboxed) if the team is evaluating whether to customize Symfony's HttpKernel for multi-tenant or request-lifecycle needs. The package demonstrates an approach, but any modern decision should be made against current Symfony docs and the symfony/http-kernel component directly, not against a four-year-old abandoned wrapper.
• Negative signal on vendor selection. If a package or vendor in your dependency graph transitively requires m6web/http-kernel-bundle, that is a risk flag worth escalating to engineering leadership — it implies the vendor has not refreshed its dependency tree since 2020, which correlates with unpatched CVEs and PHP-version incompatibility.

When to Consider This Package

Adoption criteria — essentially all of these must be true, which is unlikely:

• You are maintaining a frozen, legacy Symfony application (Symfony 3.x/4.x era, PHP 7.x) where this bundle is already installed and working, and the cost of removal exceeds the risk of keeping it. In that narrow case, "consider" means document it and ring-fence it, not adopt it.
• You need a read-only reference implementation for how a custom HttpKernel was structured in a BedrockStreaming project. Read the source; do not install it.
• You have an audit or compliance requirement to enumerate deprecated dependencies, in which case this lands on a remediation list.

Look elsewhere — which is the default answer — when:

• You are starting any new project. Use symfony/http-kernel (actively maintained, currently supported Symfony version) and Symfony's own kernel event system, bundles, and middleware. Every capability this bundle once offered is either in core Symfony now or better expressed through supported extension points.
• You need maintained, security-patched dependencies. An archived repo has no CVE response path. That is a hard blocker for anything customer-facing or handling regulated data.
• You need PHP 8.x / current Symfony compatibility. A 2020 release predates major runtime shifts; expect immediate breakage.
• Your team values hiring and onboarding. Nobody wants to explain an abandoned third-party kernel fork to a new engineer.

How to Pitch It (Stakeholders)

For executives: This is a deprecated, archived PHP package with no maintainers, no users, and no releases since 2020. It carries no product upside and introduces real downside: no security patching, no compatibility with modern PHP or Symfony, and a support burden with no owner. Recommendation is a no-go for any new use, and if it appears anywhere in our stack, treat it as technical debt with a scheduled removal. The one legitimate action is a cheap inventory check to confirm we don't depend on it — that's a half-day of engineering time, not a project.

For engineering: Treat m6web/http-kernel-bundle as a reference-only artifact. If you need HttpKernel customization, build directly on the supported symfony/http-kernel component and its event/middleware extension points; do not resurrect this wrapper. If it is present transitively in any service, flag it in the next dependency-hygiene pass — the presence of a 2020-archived dependency is a useful proxy for an unmaintained tree worth auditing more broadly. If we want the pattern it encodes, we read the source for twenty minutes and then write our own on a current Symfony baseline.