Products Review Laravel Package

Getting Started

Before you write a single line of Laravel code, internalize what you are actually installing: baks-dev/products-review is a Symfony/Doctrine bundle, not a Laravel package. There is no ServiceProvider, no artisan, no Eloquent model, no Blade view, and no config/products-review.php publish stub. It exposes its surface through bin/console baks:assets:install, doctrine:migrations:*, and a Symfony bundle registration. A Laravel dev's first day with this package is therefore a feasibility day, not a build day.

Do this in order:

1. Read composer.json before you require it. The only reliable version contract is the php constraint (>=8.4) and the symfony/* / doctrine/* ranges. If your app is PHP 8.3 or older, stop here.
2. Clone into a throwaway branch with a disposable DB. Do not run this against a shared dev database. doctrine:migrations:diff against an existing Laravel/Eloquent schema is where you will discover table collisions.
3. Inventory the schema it wants to create. After install, run doctrine:migrations:diff, then read the generated SQL. You are looking for review, rating, and any product/user foreign-key assumptions. Write down every table and column it wants to add or alter.
4. Check for a runnable spike, not a feature demo. Install, publish assets, migrate the disposable DB, and attempt to write one review row through whatever entity/service the bundle registers. If you can't get one row in and one row out in a day, the integration cost is already above the build-it-yourself threshold.
5. Decide adopt vs. build. For the vast majority of Laravel apps the correct first use case is not "wire this in" — it's "confirm the schema model and steal the entity design," then build the equivalent with Eloquent. Only proceed to a bridge if you genuinely need the bundle's business logic and are willing to own a Symfony-shim in your Laravel app.

If you do adopt, your first working day-to-day use case is a single vertical slice: product page → review list → create review with rating → persist. Get exactly that passing through the package's entity layer before any UI polish, moderation, or notifications.

Implementation Patterns

There are two honest ways a Laravel dev can run this, and you should pick one up front because mixing them produces an unmaintainable mess.

Pattern A — Process-bridge (recommended if you adopt at all). Keep the bundle isolated as a Symfony/Doctrine component and invoke it from Laravel only at the schema and CLI boundary. Concretely:

• Install the package and a minimal Symfony console kernel (or a thin bin/console bootstrapped from the bundle) inside your project, or run the bundle's commands through a dedicated process.
• From Laravel, wrap the three install steps in a custom Artisan command (php artisan reviews:install) that shells out to baks:assets:install and the Doctrine migration commands via Process::run(...). This gives your team the familiar artisan ergonomics without pretending the bundle is Laravel-native.
• Read reviews through Doctrine DBAL (DB::connection()->getDoctrineConnection() or raw DB::select) against the tables the bundle creates. You do not need Eloquent models for read paths — a read-only query builder or lightweight DTO is fine.
• Write reviews either through a small adapter service that instantiates the bundle's entity and flushes via a manually configured EntityManager, or (simpler and more common) through Eloquent models you write yourself that map to the bundle's tables. Do not mix writes through both ORMs to the same rows — pick one writer per table.

Pattern B — Build the Eloquent equivalent, use the package only as a schema/domain reference. For most Laravel teams this is the pragmatic "day-to-day leverage." Create Review, Rating, and the pivot to Product as Eloquent models. Copy the schema and validation rules from the package's entities. You get the domain shape without a cross-framework bridge. In practice this is 2–5 days of work, not the 1–2 weeks a stakeholder might fear, and it's the pattern most teams actually ship.

Day-to-day workflows once a schema exists (either pattern):

• Feature-flag the review surface behind config('features.reviews') so you can dark-launch and roll back without a deploy.
• Keep write validation in Laravel form requests even if the bundle stores the data — Laravel's validation, throttling middleware (throttle:reviews), and honeypot/spam guards are stronger than anything the package documents.
• Cache rating aggregates (avg rating, count) rather than recomputing on every product page. Review writes are the invalidation trigger.
• Treat moderation as a Laravel concern. Add a status enum column if the bundle doesn't, and query it through your own scopes — you want Review::approved() reading well in your controllers.
• Test at the boundary you own. Run the package's own suite (phpunit --group=products-review) once during the spike to prove it works, then write your own Laravel feature tests for the endpoints you build. Never rely on the package's tests as your regression net.

Gotchas and Tips

• baks:assets:install is not php artisan vendor:publish. In a pure Laravel app there is no bin/console to run it from. You either bootstrap a Symfony kernel or skip the assets entirely (you're building your own Blade/Tailwind UI anyway — the bundle ships Twig).
• doctrine:migrations:diff will not read your Eloquent migrations. It diffs the DB against Doctrine mappings only, so on an app with an existing schema it can produce destructive or duplicate SQL. Always generate the diff against a snapshot of your real schema, read the SQL line by line, and never migrate it blind. This is the single most likely way to break production.
• Version/date red flag. The last release is tagged v7.4.11 with release notes that are literally just the version string, and the listed release date (2026-05-25) is inconsistent with a normal timeline. Treat upgrade semantics as nonexistent — pin an exact version in composer.json and review source diffs before bumping.
• PHP 8.4+ is a hard floor. If your production fleet runs 8.2/8.3, this is a non-starter without a compatibility fork.
• Zero stars, zero dependents, MIT. Assume no upstream support and no security advisories. If you ship this, you are the maintainer. Fork it into your own namespace rather than depending on the upstream repo long-term.
• No moderation, i18n, spam, GDPR, or API features are documented. Do not assume they exist. If the package stores raw reviews, add your own soft-delete/export path for GDPR and your own moderation state machine — do not wait for the package to provide them.
• Product association is the risky seam. The bundle assumes a product entity it can join to. If your products live in Eloquent tables, the foreign keys may not line up cleanly, and the Doctrine entity may expect a different primary-key type. Verify the join column types explicitly.
• Rollback discipline. Before running the generated migration anywhere shared, confirm the migration is reversible (doctrine:migrations:migrate prev) and have a DB backup. Asset publishing, once it overwrites, is not automatically restored.
• Debugging tip: when a Doctrine flush fails inside a bridge, the most common cause is a detached/stale EntityManager after a Laravel request boundary. Either configure one EntityManager per request or, preferably, keep all review writes in a single dedicated service that you can unit-test in isolation.
• Extension point: if you keep the bundle, wrap it behind your own ReviewRepository interface in Laravel. That interface is your escape hatch — you can swap Pattern A for Pattern B (or a future spatie/laravel-reviews-style package) without touching controllers. This is the decision that keeps the "zero-maintenance community" risk from becoming your problem.