Nghttpbundle Laravel Package

Product Decisions This Supports

• Legacy modernization triage. The package marks a specific coupling seam — AngularJS $http calls against a Symfony backend, including CSRF/session handling and route exposure. Identifying that seam is directly useful when scoping an AngularJS-to-modern-Angular migration: it tells you exactly which HTTP layer, auth handshake, and route-generation glue has to be rewritten rather than guessed at.
• Build vs. buy on integration glue. The "integration" here is thin configuration and a small amount of middleware. That reframes the decision from "adopt a dependency" to "write ~100–200 lines in-house and own it," which is almost always the cheaper, lower-risk path.
• Platform standards / approved-stack calls. Zero stars, zero dependents, and no visible release cadence is a clear signal for a "do not standardize" decision. Useful as a documented precedent when someone proposes a niche bundle as a team standard.
• Third-party and supply-chain risk register. A concrete example for bus-factor and abandonment screening: MIT license means fork-and-freeze is viable; the absence of adoption means no security response and no upstream compatibility work for PHP 8 or Symfony 6+.
• Scope/fit correction. It is not a Laravel package despite the generic "Laravel/PHP" framing — it is a Symfony bundle targeting an AngularJS-era front end. For a Laravel roadmap item, this is out of scope entirely and should be closed rather than evaluated.

When to Consider This Package

Consider it only when:

• You are maintaining a Symfony application (likely 2.x/3.x era) whose front end is AngularJS 1.x and already relies on $http against Symfony endpoints.
• You need to preserve CSRF token handling, session-based auth, or server-generated routes for that front end during a short, time-boxed maintenance or migration window.
• You are willing to vendor the code under MIT, pin it, and treat it as frozen internal code rather than a live dependency.

Look elsewhere when:

• The stack is Laravel. There is no Laravel integration here; use Laravel's own HTTP/API tooling.
• The front end is modern Angular (2+). $http no longer exists; HttpClient plus conventional JSON REST endpoints removes the need for this bundle entirely.
• You need maintained dependencies. Zero stars and zero dependents means no community validation, no issue triage, and no compatibility guarantees for current PHP or Symfony releases.
• You need real auth infrastructure. Token-based auth, OAuth2, or SSO should go through dedicated, maintained libraries (Sanctum/Passport on the Laravel side, standard Symfony security on the other) — not a bespoke bundle.
• Your need is small. Which it almost certainly is: an in-house shim costs less to build than the review, pinning, and eventual replacement of an unmaintained bundle.

How to Pitch It (Stakeholders)

For executives: This is not a strategic dependency and should not enter the approved stack. It has no adoption signals — zero stars, zero dependents — so there is no community, no security response, and no maintenance guarantee. The problem it solves is narrow and legacy: connecting an old AngularJS front end to a Symfony backend. Our recommendation is no adoption for new work, and for any existing app that uses it, a fork-and-pin with a scheduled replacement.

For engineering: It is a thin Symfony bundle bridging AngularJS 1.x $http to Symfony — CSRF handling, session auth, and route exposure. That surface is small enough to reimplement in-house in under a week, with full control and no abandonment risk. If already in production, fork it under the MIT license, pin the version, and fold removal into the front-end migration ticket so the seam gets deleted rather than carried forward.