- Is ruwork/ruwork-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle from the Ruwork family published by Ruvents, not a Laravel package. Bundles register services, configuration trees, and compiler passes into the Symfony kernel, which has no equivalent in Laravel's service provider model. If you are evaluating this for a Laravel application, the framework mismatch ends the evaluation immediately.
- Can I install ruwork/ruwork-bundle in a Laravel application?
- No. There is no meaningful adapter path between a Symfony bundle and Laravel's container, so composer require would at best pull in dead code you cannot boot. The correct action for a Laravel codebase is to reject the dependency and, at most, read the source for design ideas. Do not port the code; write the small utility natively in your own namespace with tests.
- Is ruwork/ruwork-bundle still maintained?
- No, the repository is archived, which means no upstream fixes, no compatibility releases, and no security response. The code dates from roughly the PHP 7.x and Symfony 3.x to 4.x era. Zero stars and zero dependents also means there is no field validation and no community to ask about failures.
- Which PHP and Symfony versions does ruwork/ruwork-bundle support?
- Based on its publication period, the bundle targets PHP 7.x with Symfony 3.x and 4.x. Composer resolution against a modern PHP 8.x and Symfony 6 or 7 runtime will almost certainly fail or force constraint overrides. Forcing an install with --ignore-platform-reqs converts a dependency into a liability rather than solving the problem.
- What does the Ruwork Bundle actually contain?
- The name and description suggest a metapackage that aggregates reusable Ruwork services, configuration, and sibling bundles into one install. If that is accurate, adopting it means adopting the entire surface area instead of the single capability you need which is a poor trade. Before any spike, enumerate the specific behaviours you actually want so you can judge whether they are thin wrappers you could reimplement quickly.
- Composer fails to resolve ruwork/ruwork-bundle on Symfony 6 or 7. What should I do?
- Do not widen constraints or skip platform checks to force it in. If a spike is genuinely warranted, run it on a throwaway branch, attempt composer require, and capture the resolution report verbatim including conflicts, forced downgrades, and abandoned transitive packages. Record the exact PHP and Symfony constraint set that resolves, then decide whether that set is acceptable for your service.
- What are the maintained alternatives to ruwork/ruwork-bundle for a Symfony application?
- Because the bundle is an aggregate of small utilities, the practical alternative is usually native code. Choose in order of preference: adopt a maintained upstream package that covers the single behaviour, or reimplement that behaviour in your own bundle or src namespace with tests. Forking one sub-bundle into an internal repository is the fallback and should require a named owner and a deprecation date at approval time.
- How should I test ruwork/ruwork-bundle before committing to it?
- Run the spike on a disposable branch and treat container compile and cache warmup as the first smoke test, since bundle registration failures surface there. Then run your host application's existing test suite against the spiked branch to catch service wiring regressions. Capture the Composer resolution output and the exact dependency versions so the result is reproducible.
- Is ruwork/ruwork-bundle safe to use in production?
- The technical risk is high and asymmetric. The downside, such as an unpatched transitive dependency or silent breakage on a framework upgrade, is borne by your team, while the upside is a few small utilities that are trivially replaceable. Additional concerns include unknown code provenance, unknown test coverage, and documentation drift.
- Can I fork ruwork/ruwork-bundle or copy its code into my project?
- The bundle is MIT licensed, so forking is permitted provided the copyright notice and attribution chain are preserved and verified as clean. Prefer forking only the single sub-bundle you need into an internal repository under your own namespace rather than the whole metapackage. Any approved fork should have an explicit owner and a deprecation or exit date recorded at the moment it is approved.