- Can I use skigun/legacy-wrapper-bundle in a Laravel application?
- No. It is a Symfony bundle built around Symfony's HttpKernel and sub-request dispatch, and Laravel has no bundle system or equivalent kernel contract for it to hook into. Its symfony/symfony ~2.x constraints and PHP 5.x idioms will also fail dependency resolution on Laravel 10 or 11 with PHP 8.1+. Treat the repository as reference material for migration design, not as a Composer dependency.
- What does skigun/legacy-wrapper-bundle actually do?
- It boots a legacy PHP front controller inside the modern Symfony request lifecycle so selected routes can still be served by the old codebase. It forwards matching paths to legacy entry points, bridges request, response and session state, and exposes Symfony services to legacy scripts through a simple container. It is a Symfony 2-era piece of Theodo's Evolution toolkit aimed at incremental migration rather than a rewrite.
- How does the bundle route requests to legacy PHP code?
- Routes the modern application does not own are intercepted and dispatched as in-process sub-requests to the legacy front controller, based on configurable rules. Request and response objects plus session state are translated across the boundary. The nearest Laravel equivalent is an ordered catch-all or Route::fallback() that hands off to a legacy handler.
- How do I install skigun/legacy-wrapper-bundle?
- You cannot meaningfully install it into a Laravel project. A composer require targets Symfony 2-era applications and its version constraints conflict with modern PHP and current Laravel releases. Clone the repository, read the routing and session bridging code, and use it as a design reference instead.
- Which Laravel and PHP versions does this package support?
- None. The package supports no Laravel version at all and was written for Symfony ~2.x with PHP 5.3 to 5.6 conventions. Expect install failures on PHP 8.1+ and on Laravel 10 or 11. There is also no upstream activity adding PHP 8 compatibility or security patches.
- What is the Laravel equivalent of this bundle's legacy request forwarding?
- Use an ordered catch-all route, Route::fallback(), or explicit route exclusions to hand unmatched paths to legacy code. For most teams the stronger option is a reverse-proxy strangler fig where nginx, Envoy or an ALB sends unmatched paths to the legacy vhost while Laravel owns new routes. That keeps a single domain and correct cookies, allows independent deploys, and gives a clean rollback point at the proxy.
- How does the bundle share sessions and authentication with legacy code?
- It reuses the Symfony security context inside legacy scripts and bridges session state so the old code sees an authenticated user. In a Laravel migration the realistic choices are a shared session store such as Redis, a signed interop token, or forced re-authentication at the boundary. Prefer the signed token because it gives one authoritative issuer and a clean revocation story.
- Is skigun/legacy-wrapper-bundle maintained and safe for production?
- No. It has zero stars, zero dependents, no visible production users, and no upstream to absorb PHP 8 deprecations or security fixes. In-process dispatch also pulls legacy fatals, output-buffer leaks and header collisions into the modern request lifecycle, and offers no hooks into Laravel's logging, tracing or exception handler. If you need this behaviour, own a fork deliberately and name an owner for it.
- What are the alternatives for gradually migrating a legacy PHP app to Laravel?
- The recommended path is a reverse-proxy strangler fig: the proxy routes unmatched paths to the legacy application while Laravel serves new endpoints. A Laravel middleware catch-all proxying outbound requests through Guzzle achieves the single-entry-point goal at the cost of an extra hop and careful streaming and header handling. Forking and porting this bundle's bridging logic is justified only under a hard infrastructure constraint plus a funded commitment to maintain the fork.
- How should I test a legacy bridge during an incremental migration?
- Test the seam rather than the frameworks: route parity, cookie and session behaviour across the boundary, header collisions, and output-buffer leakage from legacy scripts. Run a staging dual-run with contract tests between Laravel and the legacy app, and verify that rollback works at the proxy or middleware layer. Also agree who owns each database table during dual-run and what inconsistency window, such as logout loops or stray 403s, users can tolerate.