Symfony Request File Clean Bundle Laravel Package

Getting Started

First, check what you actually got: tourze/symfony-request-file-clean-bundle is a Symfony bundle, not a Laravel package. Laravel's Illuminate\Http\Request extends Symfony\Component\HttpFoundation\Request, so the underlying concern (uploaded/temporary files attached to a request lingering on disk after the request ends) is real in a Laravel app — but the bundle's delivery mechanism (Bundle class, config/bundles.php registration, Symfony's Extension/Configuration config tree) has no equivalent in Laravel. There is no service provider and no package auto-discovery, so composer require alone will do nothing in a Laravel app.

Recommended entry points, in order:

1. Read the bundle class and its DependencyInjection/ directory to see what it registers and what it hooks (kernel.request, kernel.response, or kernel.terminate).
2. Read the request-file "cleaner" service itself — that's the piece with reusable logic.
3. Read Resources/config/ (or config/) for the available knobs: which directories, which file bag (files vs files+session), and whether cleanup is opt-in or always on.

First real use case, in Laravel: don't install the bundle. Copy the pattern — delete request-attached temp files once the response is on its way out — into a terminable middleware or an App::terminating() callback. That gives you the behaviour with Laravel-native configuration, testing, and container semantics.

If you genuinely are on Symfony (or a mixed stack with a Symfony kernel), register the bundle in config/bundles.php and verify cleanup with a functional test before trusting it in production.

Implementation Patterns

Laravel-native equivalent (recommended). Scope temp uploads to a known prefix, then reap them:

• Store intermediate uploads under something like storage/app/tmp/{uuid}/ rather than the system temp dir, so cleanup is bounded and auditable.
• Register a terminable middleware (or App::terminating()) that removes only that prefix. Terminable middleware runs after the response is sent, which matches the bundle's likely kernel.terminate behaviour.
• Keep the cleaner idempotent: is_file() guard, catch and log, never throw from termination.

Whitelist over blacklist. Whatever the package's config exposes, prefer an explicit list of directories the cleaner is allowed to touch. A cleanup service with a broad default is one config mistake away from deleting user data.

Pair with validation, don't replace it. Cleanup is a safety net for files that shouldn't persist. The primary control is still "only move a file into permanent storage after validation passes." Treat the cleaner as defence in depth.

Test the lifecycle, not the service. In Laravel, Storage::fake('local') plus a request test that asserts the temp path is empty after the response is a better regression test than unit-testing a delete method — it catches event-timing regressions, which is where these packages actually break.

If you do use the bundle. Register it explicitly, publish/override config rather than editing vendor files, and decorate the cleaner service (Symfony's decorates:) if you need extra rules. Then pin the version.

Gotchas and Tips

• The 0.1.0 changelog is empty. The release note is a bare compare link (0.0.2...0.1.0) with no entries. Diff it before upgrading. In 0.x packages, a minor bump is not a compatibility promise — breaking changes are permitted by semver below 1.0, and this ecosystem's churn is real.
• Bundle ≠ Laravel package. No vendor:publish, no facade, no config/*.php you can mergeConfigFrom. Any config is Symfony Configuration YAML/PHP loaded by the kernel. Don't build a Laravel integration around assumptions from the README's Symfony snippets.
• Event timing is the sharp edge. If cleanup happens on kernel.response, anything that streams or re-reads the file afterwards (download responses, X-Sendfile, queued jobs holding a path) will fail with "file not found." Verify which event it subscribes to before wiring it into an upload flow.
• kernel.terminate is not guaranteed. It depends on the SAPI and on fastcgi_finish_request being available; under some setups termination runs late or behaves differently from expectations. Don't make cleanup the only thing standing between users and unbounded disk growth — add an out-of-band sweep (scheduled command) as a backstop.
• Debugging disappearing files. If files vanish unexpectedly, disable the bundle/cleanup step first to confirm causation, then narrow the directory whitelist. Check whether the package logs at all — if it's silent, add your own logging around the equivalent Laravel middleware rather than fighting a black box.
• Pre-1.0 pinning. Constrain to 0.1.* and read the diff on each bump. Given the empty changelogs, treat every release as potentially breaking until the diff says otherwise.
• Extension point. Decorate or replace the cleaner service (Symfony) / extract a TempFileReaper interface (Laravel) so cleanup policy lives in your code, not in vendor defaults that may shift under you in 0.2.0.