Product Recommend Bundle Laravel Package

Getting Started

This package is published by Tourze, whose bundles are Symfony-first: product-recommend-bundle is a Symfony bundle (Bundle subclass + DependencyInjection extension), not a Laravel service provider package. Before wiring it in, confirm what it actually ships by reading, in order:

1. composer.json — required Symfony/Doctrine versions and whether symfony/framework-bundle is a hard dependency.
2. src/*Bundle.php and src/DependencyInjection/ — the service wiring and any autoconfiguration/tagged interfaces.
3. src/Entity/ (or src/Model/) — the Doctrine mappings you will be adopting.
4. src/Resources/config/ — the YAML/PHP service definitions you would have to translate manually.

Minimal steps in a Laravel app:

composer require tourze/product-recommend-bundle
php artisan vendor:publish   # if a Laravel bridge exists; otherwise skip

Because the bundle registers itself through the Symfony kernel, you have two realistic paths:

• Wrap it: create a small Laravel service provider that instantiates the bundle's core services by hand (constructor injection, no container magic) and binds them as singletons.
• Skip it: borrow the domain model and recommendation logic, reimplement the persistence layer with Eloquent. For a 0.0.x package this is often cheaper than fighting the integration.

The first use case to validate is the simplest one: store a (product, recommended_product, score, type) row and read it back. If you cannot get that working in an afternoon, the package is not ready for your stack.

Implementation Patterns

Doctrine entity adoption. The bundle's value is in its entity definitions. Map them to your existing product table by primary key, and either let Doctrine manage its own tables alongside Eloquent or generate a Laravel migration from the Doctrine schema (php artisan doctrine:schema:to-migration-style tooling, or hand-write it from SHOW CREATE TABLE in a throwaway SQLite database).

Service-layer wrapping. Expose the bundle's recommendation logic behind your own interface so controllers and jobs never touch vendor classes directly:

interface Recommender
{
    /** @return RecommendedProduct[] */
    public function forProduct(int $productId, int $limit = 10): array;
}

Bind a package-backed implementation in your provider now, and a first-party implementation later if you drop the dependency. This is the single cheapest insurance policy against a 0.0.x dependency.

Asynchronous recomputation. Recommendation generation is a batch concern, not a request concern. Put the recompute behind a queued job (Laravel's queue, or the bundle's console command invoked via Artisan::call / Process), and make the read path a cheap indexed select. Never call the recommender inline in a product page render.

Caching. Treat recommendation output as a cacheable artifact keyed by product_id + strategy + version, with invalidation on recompute. This also masks any performance regressions in the package itself.

Strategy extension. Tourze bundles typically expose tagged-service extension points. If the bundle defines a recommendation-strategy interface, implement it in your app and register via a tagged binding rather than editing vendor code — this survives composer update.

Gotchas and Tips

• The 0.0.3 changelog is empty. The release note is only a compare link (0.0.2...0.0.3). Diff the tags yourself (git diff 0.0.2 0.0.3 --stat) before upgrading; pre-1.0 Tourze releases routinely change signatures without deprecation notices. Pin the exact version ("tourze/product-recommend-bundle": "0.0.3") and never use ^0.0.
• Symfony/Laravel impedance mismatch. Symfony bundle autoconfiguration depends on Kernel::registerBundles(); Laravel has no equivalent. Anything relying on compiler passes, tagged iterators, or Bundle::getContainerExtension() will silently do nothing in Laravel. Grep for TaggedIterator, ServiceLocator, and %parameter% before assuming a feature works.
• Doctrine vs Eloquent is the main friction point. Two ORMs, two identity maps, two transaction boundaries. Keep all Doctrine access inside the wrapper service and pass primitives (IDs, arrays) across the boundary — never pass Eloquent models into Doctrine entities.
• Migrations. Don't let the bundle auto-create schema in production. Diff the Doctrine mapping against a real database early and commit a hand-reviewed Laravel migration.
• Debugging. If services "aren't found," it is almost certainly the missing bundle registration, not your code. Dump the container in a bare Symfony skeleton first to get a known-good reference, then port the definitions across.
• Extension points. Before customizing, check for a Resources/config/services.php or DependencyInjection/Configuration.php — the supported override path is usually a config key or a tagged interface, not a decorated service.
• Vendor lock-in risk. At 0.0.x with no documented changelog, budget for replacing this package. The wrapper interface above is the difference between a one-file swap and a refactor.