Direct Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for ExtDirect support — resolved in favor of "build" (or more precisely, "reference and reimplement"). The package is a Symfony bundle, not a Laravel package: no service provider, no publishable config, no facade, no artisan surface. A Laravel team adopting it would spend the entire integration budget rewriting container, config, and routing wiring — which is most of the work of just writing the protocol layer. This informs a decision to budget ~300–600 lines of first-party code (roughly 2–3 weeks including a conformance harness) instead of a dependency.

• Roadmap sequencing for legacy ExtJS admin tooling. If an ExtJS console exists, this package maps the shape of the problem: an api.js descriptor loaded at client boot, a single POST endpoint that accepts batched JSON RPC calls, and per-call success/exception envelopes returned inside an HTTP 200. That is genuinely useful for scoping — it tells you the integration is a transport concern, not a domain concern, and can be isolated behind an adapter and replaced incrementally.

• Frontend modernization strategy. ExtDirect only pays off if a licensed ExtJS client exists or is contractually required. This evaluation supports a "modernize the contract, not the protocol" decision: if the frontend can move to REST/JSON or GraphQL, do that and skip the protocol work entirely. ExtJS is commercially licensed and declining; betting admin roadmap on it deserves explicit sign-off.

• Vendor and maintenance risk posture. Last release 2016-05-31, 2 stars, 0 dependents, [READ-ONLY] subtree split of a dormant upstream monorepo. There is no CVE channel, no issue triage, no PHP 8 compatibility work, and no path to upstream a patch. This supports a standing policy of rejecting it as a dependency and treating it as an MIT-licensed protocol reference (verify the license file before copying logic).

• Hiring and knowledge-transfer risk. ExtJS and ExtDirect are unfamiliar to most engineers under ~35. Any decision to keep the protocol alive carries a persistent, compounding staffing cost that belongs in the roadmap conversation alongside the technical estimate.

When to Consider This Package

Consider it (as a reference, not a dependency) when:

• A live ExtJS frontend currently speaks ExtDirect, and you need to understand the exact request/response shape, batch semantics, and api.js descriptor format before building a replacement.
• You are maintaining a legacy Symfony 2.x/3.x application where the bundle's conventions actually fit and the code is already present — here it is a "do not break it" concern, not an adoption decision.
• You need a conformance checklist: reading the protocol layer end-to-end is faster than reverse-engineering it from client behavior alone.
• The integration is short-lived, internal, and you accept full code ownership — fork, test, patch, and plan the exit.

Look elsewhere (or stop) when:

• You are building a Laravel application — this is a Symfony bundle. The container, config tree, event subscribers, and routing integration are wire-for-wire wrong and must be rewritten, not adapted. Path of least regret: reimplement the protocol surface as a first-party Laravel package.
• You need PHP 8.1+ support — expect dynamic-property deprecations, untyped internals, and Composer platform constraints that will refuse to resolve against Laravel 10/11 without a fork on day one.
• You require security maintenance, CVE response, or community support — none exist. Zero dependents means nobody has blazed the trail either.
• No ExtJS client exists today. If there is no consumer, the conversation ends; do not adopt a 2016 dependency graph into a modern application's vendor tree — transitive Symfony constraints will fight Laravel's own.
• The frontend can be changed — prefer a REST/JSON or GraphQL contract and never introduce the protocol.

How to Pitch It (Stakeholders)

Executive summary. This is an abandoned (last release 2016), near-zero-adoption (2 stars, 0 dependents) Symfony bundle that implements the server half of Sencha's ExtDirect remoting protocol for ExtJS clients. It is not a Laravel package and is not a safe dependency for our product. Its only real value is as a free, MIT-licensed specification we can read to understand a protocol we may need to speak for a legacy admin console. Recommendation: do not adopt it; if a live ExtJS client exists, fund a ~2–3 week reimplementation in Laravel behind a conformance harness and cut over with a dual-run — we own the result, it runs on our stack, and we carry no vendor risk. If no ExtJS client exists, close the evaluation.

Engineering summary. Treat the repository as a read-only protocol reference, not a package. The reusable core is narrow and well understood: request envelope parsing, batch iteration, per-action dispatch to a method registry, per-call {type: "exception"} envelopes inside an HTTP 200, and api.js generation from that same registry. The Symfony shell — bundle class, DI extension, config tree, event subscribers — is discarded entirely. Three things are load-bearing and must ship together from one source of truth: the descriptor (api.js) and the dispatcher registry, since the client loads the descriptor at boot and calls methods by name. Authorization must be resolved per action before dispatch, because one HTTP request carries many logical calls with potentially different permission requirements — Laravel's single-route middleware model does not express that, and getting it subtly wrong grants more access than intended. Design explicitly for partial batch failure, descriptor drift, session-expiry 419s that ExtJS surfaces as opaque transport errors, and session locking on parallel batches from chatty admin dashboards. Do not install it in-process for the dual-run phase: stand it up in an isolated PHP-FPM pool or microservice with its own composer.json and proxy to it. Budget a named owner, a security review of the port, and a standing item to re-verify against each PHP upgrade.