Ruwork Bundle Laravel Package

Getting Started

Before writing any code, note that the picture has shifted slightly since the last assessment. 0.2.0 is the first release since July 2018, and the changelog is two lines: "Refactoring" and "Redesigned @Redirect". That is not enough to declare the package maintained — one tag after a multi-year gap is not a maintenance cadence — but it does mean the "frozen artifact" assumption no longer holds exactly, and it means the thing you install today is not byte-identical to the thing everyone blogged about in 2018.

1. Re-check the repo state first. Confirm whether the repository is still archived and whether the composer.json constraints moved. The release notes say nothing about Symfony or PHP support, so read require yourself — do not assume 0.2.0 means "modernised." If the constraints are still Symfony 3.4/4.0-era, the compatibility friction described previously still applies.
2. Diff 0.1.x against 0.2.0 before installing. "Refactoring" with no detail is a warning, not a feature. Run git diff <last-0.1-tag>..0.2.0 -- DependencyInjection Resources and look specifically for renamed service IDs, changed tag names, and altered config keys. If you have a composer.lock pinning a 0.1 release, treat the upgrade as a breaking change until you have proven otherwise.
3. Read the DI extension again. The entry point is still DependencyInjection/RuworkExtension.php plus Resources/config/*.xml|yaml, and after a refactor those files may have been reorganised or the configuration tree renamed. This remains the real documentation.
4. Register the bundle. In a legacy app: AppKernel::registerBundles(). In Symfony 4+: add Ruwork\RuworkBundle\RuworkBundle::class => ['all' => true] to config/bundles.php.
5. Install with an exact constraint while you evaluate. Because this is a 0.x line and 0.2.0 changed behaviour, use composer require ruwork/ruwork-bundle:0.2.0 (or ^0.2 with a committed lockfile) rather than an open range. ^0.1 will not pull 0.2.0 under Composer's 0.x semantics, which is good — an accidental upgrade should be impossible.
6. First use case. The headline change is the redesigned @Redirect annotation. Find its class in the repo (grep -r "class Redirect" src/), read the annotation's constructor and properties, then use it on a controller action and confirm the redirect actually fires. Annotation-driven behaviour fails quietly — a renamed property or a missing use statement produces a controller that returns 200 instead of redirecting, with nothing in the logs.

Implementation Patterns

Day-to-day usage remains configuration plus consuming tagged services, but the annotation layer is now the part most likely to be in your code.

• Annotation usage, verified end to end. The redesign means the arguments you pass to @Redirect may differ from the 0.1 shape. Inspect the class properties rather than copying an old snippet from a blog post — most public examples predate this release and will be wrong. Add a functional test that asserts the response status and Location header, not just that the annotation parses.
• Configuration-driven setup. Put bundle options under the ruwork: root key in config/packages/ruwork.yaml (or app/config/config.yml on Symfony 3). Mirror the defaults from the Extension class — after a refactor, do not assume your existing keys survived. Configuration.php's TreeBuilder is authoritative.
• Service decoration over fork. When you need to change behaviour, decorate the bundle's services in your own services.yaml with decorates: ruwork.some_service rather than editing vendor code. This is even more important now: if a 0.3.0 refactor lands in another six years, your decorations are the only thing you have to re-verify.
• Consume tagged services. The bundle collects services by tag via compiler passes. Register your own classes with the same tag and let the bundle's pass collect them — the intended extension point. Re-confirm the tag names after the refactor with grep -r "findTaggedServiceIds" src/.
• Isolate the annotation behind your own abstraction. If @Redirect is doing real work in your controllers, consider a small RedirectResolver service of your own that wraps the bundle's logic. The annotation syntax just changed once with no migration guide; assume it can change again.
• Pin and stage the upgrade. For an existing 0.1 install, do the bump on a branch, run the full suite plus a container-warmup check, and read the resulting debug:container diff. Commit the lockfile.
• Sub-package extraction. Audit which Ruwork components the bundle actually wires, then require those individually — check the repo's own composer.json for the real list. You often only need the redirect piece, and the umbrella adds coupling for no benefit.

Gotchas and Tips

• "Redesigned" means breaking, and 0.x semver permits it silently. 0.1 → 0.2 is a minor-version bump only by convention; in the 0.x range the author is explicitly allowed to break you. There is no migration guide in the release notes. Budget a half-day for a diff review, not an afternoon composer update.
• Annotation failures are silent. A renamed property on @Redirect, a dropped namespace, or a no-longer-imported annotation class usually degrades to "nothing happens" rather than an exception. If the redirect stops working after the upgrade, check the annotation use statement and the target class's property names first — before you suspect routing or middleware.
• Archived-or-not, the security posture is unchanged. One refactor release does not create a maintainer team or a CVE process. If any component parses user input (redirect targets are a classic open-redirect vector — check whether an untrusted parameter can reach the redirect target), review it manually before exposing it publicly.
• Zero dependents is still a signal. No ecosystem usage means no Stack Overflow answers and no one else has hit your bug. debug:container, debug:router, Xdebug, and reading source remain your primary tools.
• Symfony version skew is still the biggest trap. The release notes say nothing about compatibility, so assume the 2018-era assumptions may persist: ContainerAwareInterface, getParameter() from the container, autoconfigure defaults that changed in 4.4/5.0. Symptoms: services not autowired, ServiceNotFoundException, "cannot autowire argument" at cache warmup. Fix by defining arguments explicitly rather than relying on autowiring.
• Refactors move service IDs. After "Refactoring," an ID like ruwork.some_service may have been renamed or split. Anything you reference in decorates:, in a compiler pass, or in $container->get() is now a guess — re-derive the IDs from bin/console debug:container --tag=<tag>.
• Deprecation noise. On Symfony 4.4 you may still see a flood of deprecations from the bundle that mask your own. Filter with SYMFONY_DEPRECATIONS_HELPER so your signal stays clean.
• Config quirks. Legacy bundles often default booleans to false and silently no-op if a required key is absent. If nothing happens after enabling, dump the resolved config (config:dump-reference ruwork if supported, otherwise read Configuration.php) and confirm your keys are actually being read — and that they still exist post-refactor.
• Testing. Run with framework.test: true and assert both wiring and behaviour: self::getContainer()->get('ruwork.some_service') plus a request-level test that hits an annotated controller and asserts the redirect. That way a future release or a Symfony bump fails in CI rather than in production.
• Exit strategy is unchanged, and still the default recommendation. The bundle is a thin aggregator. Copy the handful of service definitions you actually use into your own services.yaml and drop the dependency. A redesign shipped years after the fact does not fix the underlying risk: no maintainers, no dependents, no security process.