Symfony Rotate Profile Storage Bundle Laravel Package

Getting Started

• Install with composer require tourze/symfony-rotate-profile-storage-bundle:^0.1.1. Treat the version as a pin: this is a 0.1.x package with no BC promise.
• This is a Symfony bundle, not a Laravel package. There is no service provider, facade, or config/*.php to publish. In a Laravel app you will not get auto-wiring; you'd have to instantiate the underlying services manually or via a small bridge binding in a service provider. In Symfony, confirm auto-registration by checking that the bundle FQCN (Tourze\RotateProfileStorageBundle\RotateProfileStorageBundle, following the vendor's naming convention) is present in config/bundles.php after Flex runs, or register it yourself.
• Where to look first, in this order:
  1. composer.json — type (symfony-bundle), extra.symfony.bundle, and the require list. The requires tell you more about the actual feature surface than the README usually does.
  2. The bundle class and DependencyInjection/*Extension.php — this is where config keys and service IDs are defined.
  3. Any Attribute/ or Annotation/ directory — the tourze bundles typically auto-tag services via PHP attributes plus a compiler pass, so this is the real "API".
  4. Resources/config/services.* — the concrete service IDs and their tags.
• First use case to validate end-to-end: define two named storage profiles (e.g. a "hot" and a "cold"/archival target), point the rotation rule at a write path, and confirm that writes land in the expected profile. Do this with a scratch kernel test before wiring it into anything real.
• Note on 0.1.1: the release notes are only a compare/0.1.0...0.1.1 link with no described changes. Before adopting, run composer diff tourze/symfony-rotate-profile-storage-bundle 0.1.0 0.1.1 (or read the compare view) and treat the changelog as unreviewed until you do.

Implementation Patterns

• Config-first registration. Most of these bundles expose a single extension alias (typically derived from the bundle name) with a profiles: / storages: map. Start there, get one profile resolving from the container (bin/console debug:container <id>), then add rotation rules.
• Attribute-driven registration. If an Attribute/ directory exists, the intended pattern is decorating your own storage/profile classes with the attribute and letting the compiler pass tag and collect them. This keeps config out of YAML but makes registration invisible at runtime — see the debugging tip below.
• Decorator around your storage layer. The pragmatic integration is to keep your existing storage abstraction (Flysystem adapter, disk, S3 client) and let this bundle decide which profile is active for a given write. Inject the profile resolver into a thin decorator rather than letting the bundle own your write path outright; it keeps the blast radius small when you upgrade through 0.1.x.
• Compiler pass as the extension point. For anything the config doesn't cover (dynamic profile selection, per-tenant resolution), add your own CompilerPass that runs after the bundle's and mutates the tagged locator/iterator. This is the supported seam; don't reach into private services.
• Testing. Do a kernel-boot test asserting the container has the expected profile service IDs and tag, plus one functional test writing to a temp directory and asserting the file lands under the rotated profile path. Inject a fixed clock if the rotation rule is time-based, otherwise your tests will flake at month/day boundaries.
• Laravel bridge, if you must. Bind the bundle's services in a provider via $this->app->singleton(...) and read the config from config/rotate_profile_storage.php, mirroring the Symfony extension's defaults. Keep this adapter tiny — you are now on the hook for the bundle's internals.

Gotchas and Tips

• 0.1.1 carries no information. The entire release note is a changelog link. Don't infer "patch = safe" from semver here; pre-1.0 packages in this ecosystem routinely change service IDs and config keys in patch releases. Diff the tag.
• Wrong framework assumption is the most common failure. Searches for the package alongside "Laravel" will surface it, but there is no Laravel integration. If you're on Laravel, budget for an adapter or pick a different package.
• Auto-registration depends on Flex. Without symfony/flex (or with extra.symfony.bundle missing), the bundle silently doesn't load and your config keys are ignored rather than erroring. Run bin/console debug:container --tags | grep -i rotate to confirm it registered at all.
• Compiler-pass services don't appear until cache clear. After changing config or attributes run bin/console cache:clear; in dev, also check var/cache/dev isn't serving a stale container. lint:container catches missing arguments early.
• Debugging checklist: debug:container --tag=<bundle-tag> for what the pass collected, debug:container <service-id> --show-arguments for what got injected, debug:config <alias> for the resolved config (catches silently-ignored keys from typo'd YAML).
• Filesystem state is the hidden dependency. Rotating profile storage implies state on disk (or in the profile target). Two workers rotating concurrently can race; wrap rotation in a lock (flock / Symfony Lock) and make sure rotated directories are writable by the web user, not just the CLI user that ran the console command.
• Non-determinism in tests. Any rotation keyed on time, size thresholds, or counter files needs a fake clock and a fresh temp dir per test. Sharing a fixture directory across tests is the usual source of "passes locally, red in CI".
• Extension point summary: config → extension for static profiles; custom compiler pass for dynamic/tagged collection; decorator on your own storage service for the actual read/write path. There is no event dispatcher surface worth relying on at this version.