Notification Bundle Laravel Package

Getting Started

Before writing any code, confirm what this package actually is: silvestra/notification-bundle is a subtree split of a Symfony bundle, not a Laravel package. The [READ-ONLY] marker means the GitHub repo is a generated mirror — commits land in the parent Silvestra/Silvestra monorepo, and issues/PRs opened against the split are effectively ignored.

Your first three lookups, in order:

1. composer.json — check the require block for symfony/* and sibling silvestra/* constraints, and the type field (expect symfony-bundle). If it pins Symfony 2.x/3.x, stop here: it will not boot on a modern Laravel app, and probably not on a current Symfony app either.
2. Entity/ and Repository/ — this is where the real value lives. Expect a Doctrine entity (something like a Notification with recipient, subject/body, read flag, timestamps) plus a repository with query methods. This is the part worth reading even if you never install it.
3. The parent Silvestra/Silvestra repo — for tests, fixtures, and the actual intended usage. The split repo alone gives you no runnable example.

Minimal realistic attempt: don't composer require this into a Laravel project. There is no service provider, no facade, no publishable config, and the Doctrine mappings won't line up with Eloquent. If you want to evaluate it, clone it into a scratch Symfony app (matching the symfony/* constraints) or simply read the entity definition.

First use case that actually maps to Laravel: the in-app notification list — recipient, message, read/unread, created-at — is the exact problem Laravel's built-in Illuminate\Notifications already solves via the database channel and the Notifiable trait. Treat this bundle as a data-model reference, not a dependency.

Implementation Patterns

If you are (unusually) in a Symfony/Silvestra app:

• Register the bundle in AppKernel/bundles.php, let Doctrine auto-map the entity, and use the bundle's repository to fetch unread notifications per user.
• Notifications are likely rendered through a controller + Twig template in Resources/views/; check there for the expected shape of the payload before building your own.
• Configuration, if any, will be under DependencyInjection/Configuration.php and consumed via YAML under config/packages/. Read that file to learn the extension alias.

The pattern a Laravel developer should actually adopt:

• Port the schema, not the code. Lift the entity's columns into a migration (notifications table: id, notifiable_type/notifiable_id or a plain user_id, type, data/body, read_at, timestamps).
• Port the repository queries to Eloquent scopes. A "fetch unread for user" repository method becomes Notification::where('user_id', $id)->whereNull('read_at')->latest()->get(), or a scopeUnread on the model.
• Use the native channels. Email, database, broadcast, and queueing are all first-class in Illuminate\Notifications; the Silvestra bundle's equivalents (if any) predate that API and won't interoperate.
• If you must keep the PHP classes, wrap them: a small adapter class that translates the bundle's entity into an array your app consumes, behind an interface you control. Do not let its namespace leak into your domain code.

Workflow tip: when reading the split repo, diff against the parent monorepo's src/Silvestra/NotificationBundle path. The split can lag the monorepo, so the "latest" code may live upstream.

Gotchas and Tips

• Read-only means read-only. Any bug you find has to be filed or patched in Silvestra/Silvestra, not here. Budget for that if you plan to depend on it.
• Zero stars, zero dependents is a signal, not a coincidence. Check the parent repo's last commit date and open-issue count before investing time. A subtree split with no adoption usually means the parent project is dormant.
• Symfony-version lock-in is the hard blocker. Old bundles use Symfony\Component\HttpKernel\Bundle\Bundle, service definitions in XML/YAML, and Doctrine annotations. None of that is Laravel-compatible, and modern PHP (8.2+) will likely trip deprecations or hard errors.
• Naming collision trap. Its classes will live under Silvestra\NotificationBundle\.... This is not Illuminate\Notifications — no Notifiable trait, no Notification::send(), no channel abstraction, no queue integration. Don't assume API parity from the word "notification."
• Doctrine vs. Eloquent. Even if the entity maps cleanly, Laravel's conventions (plural table names, created_at/updated_at, soft deletes) differ. Expect to rewrite the mapping by hand.
• No publishable config. In Symfony the config lives in config/packages/*.yaml under the bundle's extension alias; there is no php artisan vendor:publish equivalent and no config/notification.php to override. Read Configuration.php to enumerate the knobs.
• Debugging has no Laravel story. No Telescope, no Horizon, no Log:: facade. If you somehow get it running under Symfony, you're on Monolog and the Symfony profiler.
• Forking is a commitment. If you fork, fork the monorepo, not the split — otherwise you inherit a sync problem the moment upstream moves, and you lose the subtree-split history.
• Extension points are effectively nil from Laravel. There's no event dispatcher bridge, no container binding you can override. The only sane integration surface is "copy the model, discard the bundle."

Bottom line: treat silvestra/notification-bundle as a readable reference for notification modelling in a Symfony CMF, not as an installable dependency for a Laravel application. The day-to-day leverage is zero unless you're maintaining a Silvestra install — in which case, work from the parent monorepo and pin your Symfony version deliberately.