- Is saa/zymfony-bundle a Laravel package?
- No. It is a Symfony bundle with no Laravel service provider, facade, config file, or Laravel-specific integration surface of any kind. If it appeared in your candidate list from a Laravel or generic PHP search, that tag is wrong, and the architecture fit for a Laravel application is effectively zero. It only makes sense inside a Symfony kernel that needs to coexist with a legacy Zend Framework 1 application.
- What does saa/zymfony-bundle actually do?
- It ships a set of bridge components intended to let a Zend Framework 1 application and a Symfony 4 application run in the same process during a strangler-fig migration. The bundle provides its own configuration, service wiring, and defaults so you can register it in a Symfony kernel and expose Zymfony features with minimal setup. It is not a general-purpose compatibility layer and it is not a rewrite tool; it is interim plumbing for the period where both frameworks are alive at once.
- How do I install saa/zymfony-bundle with Composer?
- The normal path is composer require saa/zymfony-bundle followed by registering the bundle in your Symfony kernel and adding its configuration. Before you commit, confirm which versions are actually tagged, because the repository metadata does not show a release cadence and dev-master may be the only installable constraint. You also need to verify that it installs cleanly on your PHP version, since Symfony 4.4 era code targets PHP 7.x and the PHP 8.x story is unproven.
- Which Symfony versions does saa/zymfony-bundle support?
- The package name and description pin it to Symfony 4, which reached end of life in November 2023. Whether it runs on Symfony 5.4 or 6.x is unknown and likely untested, so planning a Symfony 6 target effectively means planning a fork. Budget for that maintenance work up front rather than discovering it mid-migration.
- Does saa/zymfony-bundle work with PHP 8?
- That is not answerable from the package metadata and must be verified by reading the repository and running its example end to end. Symfony 4.4 supported PHP 7.x, and a bridge layer from that era will often trip on PHP 8 type and deprecation changes. Test it on your actual runtime before you treat it as a dependency.
- Is saa/zymfony-bundle maintained, tested, and safe to depend on?
- The signals are weak: roughly 32 stars, zero dependents, a single consultancy as maintainer, and no visible test suite or CI in the scoring profile. A bridge layer without tests is a reference implementation, not a dependency you can lean on. Practically, you should adopt it as a code sample you will own and support internally, and verify issue and pull request responsiveness before relying on upstream fixes.
- When is this ZF1 to Symfony bridge actually worth using?
- It is worth considering only if you own a large Zend Framework 1 estate and have already chosen Symfony as the target, and you need both frameworks running side by side during cutover. That capability is genuinely scarce, since most migration guidance amounts to rewriting everything at once. Treat it as a conscious, time-boxed decision with an exit date, because both ZF1 and Symfony 4 are end-of-life and you are deliberately standing up two dead frameworks as your migration substrate.
- What parts of ZF1 does it bridge — routing, container, session, auth, forms?
- The metadata does not say, and the answer changes the value proposition significantly. Bridging routing alone might save days, while bridging the container, session handling, Zend_Auth, view helpers, and form decorators could save weeks. Read the source and any example application before estimating effort, and assume nothing beyond what you can see working.
- Will it work in long-running workers like RoadRunner, Swoole, or Messenger consumers?
- Unlikely without significant work, and it should be considered out of scope until proven otherwise. Zend_Registry, the Zend_Controller_Front singletons, and ZF1 superglobal reads do not compose well with Symfony's request-scoped services, and a bridge like this can leak state across requests in a long-running process. Plan on traditional PHP-FPM for the coexistence period.
- What are the alternatives and how does the licensing work if I fork it?
- Alternatives are a big-bang rewrite, a hand-rolled bridge, or strangling at the routing or subdomain boundary so only one area cuts over at a time. The license is MIT, which is permissive and fully mitigates the fork-and-maintain-internally risk, so you can vendor and modify it freely. Given the vendor risk and thin ecosystem, forking internally with a clear owner is a reasonable default.