Symfony Scan Detect Bundle Laravel Package

Getting Started

tourze/symfony-scan-detect-bundle is a Symfony bundle, not a Laravel package — the 0.0.2 release is a patch bump with no published changelog detail (compare/0.0.1...0.0.2 link only), so treat the delta as unknown and verify after upgrading.

composer require tourze/symfony-scan-detect-bundle:^0.0.2

Where to look first, in this order:

1. vendor/tourze/symfony-scan-detect-bundle/composer.json — check autoload.psr-4, require (especially the symfony/http-kernel constraint, which determines whether it can coexist with Laravel's Symfony components), and extra.laravel (a service provider here would change everything below).
2. vendor/tourze/symfony-scan-detect-bundle/src/ — locate the *Bundle class, the DependencyInjection/Extension class, and whatever the "scan detect" domain object actually is (detector, scanner, matcher).
3. The Resources/config/services.* files, if present — this is the real list of services you will be re-registering by hand.

First use case: instantiate the detector directly rather than through the container, to confirm the API before wiring anything.

// tinker
$detector = app(\Tourze\ScanDetectBundle\...\Detector::class);

If that class needs constructor arguments from the bundle's service definitions, resolve them manually — that tells you immediately how much wiring work the integration needs.

Implementation Patterns

Manual bundle registration. Laravel does not boot Symfony bundles. You either (a) use the package's classes as plain services and wire them yourself, or (b) register the bundle into a real Symfony Kernel that you boot inside a service provider. Option (a) is almost always the right call for a 0.0.x bundle; option (b) drags in kernel boot, cache warmup, and bundle ordering.

final class ScanDetectServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->singleton(Detector::class, fn ($app) => new Detector(
            $app->make(SomeMatcher::class),
            config('scan-detect.threshold', 0.75),
        ));
    }
}

Mirror the bundle's Extension config into config/scan-detect.php. Symfony Configuration trees are not loaded in Laravel, so any scan_detect.* parameters in the bundle's extension class must be copied out and registered as a Laravel config file, then injected at bind time. Diff the extension class against your config on every version bump — this is the single most common source of silent misbehaviour.

Wrap the detector behind your own interface. For a 0.0.x dependency this is non-negotiable; it lets you swap or vendor-patch the package without touching call sites.

interface ScanDetector
{
    public function detect(string $payload): ?ScanResult;
}

final class BundleScanDetector implements ScanDetector { /* delegates */ }

Job/queue pattern for real scanning work. Detection tends to be I/O-bound; dispatch it from a listener rather than in the request cycle.

// app/Listeners/DetectScanOnUpload.php
public function handle(FileUploaded $event): void
{
    DetectScanJob::dispatch($event->path);
}

Integration tip: bind to Laravel events rather than the bundle's Symfony event dispatcher. If the bundle dispatches ScanDetectedEvent, bridge it in your provider by registering a listener that re-dispatches onto Laravel's dispatcher — this keeps the rest of the app on familiar ground.

Gotchas and Tips

• 0.0.x semver means every patch can break you. With no readable changelog for 0.0.2, pin exactly (0.0.2) and read the diff (composer diff? — better: git diff the vendor directory before/after, or composer require with a VCS repo in a scratch project) before rolling out.
• No auto-discovery. Unless extra.laravel.providers appears in composer.json, nothing registers itself. php artisan vendor:p publish will fail silently with no published resources.
• Symfony component version conflicts. Laravel 10/11 ships specific symfony/* versions; a bundle requiring an older symfony/http-kernel constraint will produce an unresolvable set. Check with composer why-not symfony/http-kernel <version>.
• Config caching bites hard here. If you copy Symfony Configuration defaults into config/scan-detect.php, run php artisan config:clear after any change; a cached config with a stale threshold is a plausible cause of "detection suddenly stopped working".
• Debugging: app(Detector::class) throwing a BindingResolutionException means you missed a constructor dependency that the bundle's services.yaml used to supply. Cross-reference the YAML line by line.
• Extension points you likely can't use. Symfony compiler passes and prepend()/Extension hooks aren't invoked by Laravel. If the bundle exposes customisation only via a compiler pass or a tagged service collection, you will need to construct those collections manually in your provider.
• Watch for facades and static state. Some tourze bundles lean on static registries; in an Octane environment this leaks between requests. If you deploy under Octane, explicitly test for state bleed before shipping.
• Upgrade checklist for 0.0.2: re-read the *Bundle and Extension classes, confirm no constructor signatures changed, and re-run your own integration test that exercises detection end-to-end — vendor diffing is the only reliable substitute for the missing release notes.