- What is survos/fw-bundle and what does it actually do?
- survos/fw-bundle is a Symfony bundle described as providing reusable framework utilities for Symfony 7 applications: shared services, sensible configuration defaults, and helpers intended to reduce boilerplate across projects. It is distributed via Composer and is meant to be easy to extend or override in your own application. The 1.0 release notes only say "initial version", so there is no published feature list, API reference, or changelog detail beyond that one-line description. Treat the description as a summary of intent and confirm the actual contents by reading the bundle source before you commit to it.
- Can I use survos/fw-bundle in a Laravel application?
- Not directly, and not without work. This is a Symfony bundle, so it expects Symfony's kernel and bundle registration model via config/bundles.php and Symfony Flex, not a Laravel service provider registered through package discovery. Nothing in the package description or release notes indicates illuminate/* dependencies, a Laravel service provider, or a facade. If you need the behaviour in Laravel, plan to port or wrap the underlying code rather than installing the bundle as-is.
- How do I install survos/fw-bundle with Composer?
- Run composer require survos/fw-bundle in the project where you want it. With Symfony Flex installed the bundle should be auto-registered in config/bundles.php; without Flex you must add it to that array manually. Before running the command, check the php and symfony/* constraints in the package's composer.json to confirm they match your runtime, since Symfony 7 requires PHP 8.2 or newer.
- Which Symfony and PHP versions does survos/fw-bundle support?
- The overview states it is a bundle for Symfony 7, which implies PHP 8.2 or later as a minimum. The exact php and symfony/* constraints are not published in the release notes, so read composer.json in the tagged release before you install. If the constraints pin narrowly, record that pin as a known upgrade blocker so it surfaces during your next framework upgrade rather than at the point of failure.
- Is survos/fw-bundle stable enough to depend on in production?
- The 1.0 tag is a meaningful signal: the maintainer is asserting API stability under semantic versioning, which shifts the package from "evaluate only" to "safe to build against" in principle. Against that, this is a zero-adoption first release with no changelog detail and no field evidence, so provenance and bus factor are unknown. A sensible middle path is a time-boxed spike, a pinned version constraint, and a thin adapter so the bundle can be swapped out without a rewrite.
- Does survos/fw-bundle have a test suite and CI?
- That is not evident from the release notes or the README excerpt, both of which are effectively empty of engineering detail. Check the repository for a phpunit or pest configuration, a GitHub Actions workflow, and a matrix that covers the PHP and Symfony versions you run. Absence of tests and CI is a legitimate adoption blocker for a package that promises semantic-versioning stability from its very first tag.
- Does survos/fw-bundle register global services, routes, or middleware?
- As a Symfony bundle it can register services, load routing files, and apply configuration defaults through its DependencyInjection extension, and it may use compiler passes or bundle prepend logic. Because the package advertises "sensible configuration defaults", verify what it sets implicitly and whether each behaviour can be disabled in your app config. Undisableable global side effects are the most common source of unexpected production behaviour, so inspect the extension class before enabling the bundle outside a scratch environment.
- What are the alternatives to survos/fw-bundle?
- For Symfony projects, the safest alternatives are the first-party symfony/* components plus a small amount of in-house glue code you own outright. For Laravel work, illuminate/support and the framework's own helpers cover most of what a "framework utilities" bundle typically provides. As a rule, a utility package adopted by only one of your services is better vendored as application code, because you keep full control of the upgrade path.
- Who maintains survos/fw-bundle and is it actively maintained?
- It is published under the Survos organisation, but the release history shown here consists of a single 1.0 tag with terse notes, so no maintenance cadence is observable. Assume a bus factor of one until you have checked the commit history and issue-response times over the last six to twelve months. If the cadence is thin, pin the version explicitly and avoid relying on the package for anything on a critical path.
- How would I migrate away from survos/fw-bundle later?
- Keep every call site behind an interface or adapter you own, so the bundle is an implementation detail rather than a dependency spread through your codebase. Introduce it behind a feature flag during the spike, and keep any existing in-house implementation in place for at least one release cycle so rollback is a config change rather than a refactor. Also confirm the licence in composer.json is compatible with your distribution, since licensing is not stated in the release material.