Symbok Bundle Laravel Package

Getting Started

Framework check first. mtarld/symbok-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no #[Scope]-style integration, and no bridge into the Laravel container. If you are looking at this from a Laravel codebase, the correct move is don't install it — read it as a reference for what annotation-driven accessor generation looks like, and then solve the same problem with PHP 8.1+ constructor property promotion and readonly properties. Installing it in Laravel buys you nothing the language doesn't already give you, and adds an archived vendor to your supply chain.

If you are legitimately inside a Symfony 4/5 codebase with a large boilerplate backlog:

1. composer require mtarld/symbok-bundle on a throwaway branch — the repo is archived, so treat the version you install as the version you own forever.
2. Register the bundle in config/bundles.php.
3. Look first at the annotation classes under src/ (and the compiler pass that consumes them) — in an archived package the code is the documentation; the README may not have tracked the implementation.
4. First use case: take a single DTO with 5+ properties and hand-written getters/setters. Add a class-level @Getter / @Setter above it, run bin/console cache:clear, then var_dump((new ReflectionClass(MyDto::class))->getMethods()) to confirm the generated methods exist. One class, one verification, then stop and decide whether the ergonomics justify the ownership cost.

Implementation Patterns

The bundle's model is Lombok-style: you annotate a class or property and a Symfony compiler pass generates accessor/mutator methods at build time.

• Class-level @Getter / @Setter. The high-value default. One annotation on the class generates accessors for all properties — this is where the "10 lines per property tax" gets paid back. Use it on DTOs and value objects; think twice on Doctrine entities where you want fine-grained control over which fields are mutable.
• Property-level annotations. @Getter on a single property is the escape hatch when one field needs a getter but the rest should be write-only, or when one accessor needs custom logic that the generator would clobber. Expect to drop to property-level on ~10–20% of real entities.
• Collection helpers. @Adder / @Remover generate the addFoo / removeFoo pair alongside the getter — the canonical pattern for $tags, $roles, $members properties on Doctrine entities. This is the pattern that reads best in controllers and form types, because addRole('admin') is idiomatic where $user->setRoles(array_merge(...)) is not.
• @Constructor. Generates an all-args constructor from the class properties. This is the strongest argument for the package on PHP 7.x, because it's the closest thing to constructor promotion you can get without PHP 8. On PHP 8.0+ it is strictly worse than native constructor promotion, and you should skip it.
• Combine with a real DI pattern. Symbok generates methods; it doesn't do container wiring. Pair with plain constructor injection (or Symfony autowiring) as you would without the bundle. Don't expect this to replace services.yaml entries.
• Static-analysis stubs. If PHPStan/Psalm must see the generated methods, plan to commit stub files or run analysis only against a warm cache — see gotchas. This is the single biggest integration cost in a modern CI pipeline.

Gotchas and Tips

• Archived, zero dependents. Every bug you hit is your bug. There is no upstream patch, no CVE response, and no community troubleshooting corpus — 48 stars means Google and LLMs will confidently hallucinate behaviors. Verify against the source, not against generated advice.
• Annotations are a dead-end idiom. Symfony has been moving to native PHP attributes for years and Doctrine annotations are being retired. Building new work on an annotation-based bundle is betting against the platform's direction. If you adopt, adopt it as a transitional dependency with a scheduled removal.
• PHP 8.1+ makes most of it redundant. Constructor promotion, readonly, and native attributes remove the motivation for @Constructor, @Getter on immutable DTOs, and — partly — @Setter. Run the numbers: a one-time refactor to PHP 8.1 syntax is cheaper than permanent ownership of an unmaintained fork over more than a quarter.
• IDE and static analysis won't see generated methods. Methods are produced at container compile time, so a cold checkout will red-squiggle every call site and PHPStan/Psalm will report "method does not exist" unless you have a warm cache or committed stubs. Debugging this is a recurring tax; document the workflow (cache:clear, stub regeneration, analysis order in CI) or new team members will burn half a day on it.
• Cache warmup is the failure surface. Annotation parse errors manifest at cache:clear / container compile, i.e. at deploy time, not at test time. Always run a prod-like build (APP_ENV=prod bin/console cache:warmup) before merging, or you will ship cache-warmup crashes.
• Manual methods win, silently. If you hand-write a method that the generator also wants to produce, behavior depends on the compiler pass's ordering and conflict rules — and it is not documented. Grep your codebase for duplicate names before annotating a class. If a conflict surfaces, property-level annotations are usually the cleanest escape hatch.
• Entity mutability traps. Class-level @Setter on a Doctrine entity gives you setters on $id and $createdAt too, which is almost never what you want. Prefer property-level @Setter on entities; reserve class-level for DTOs and value objects.
• Don't expect a Laravel path. There is no adapter, no ServiceProvider, and no reusable ecosystem. Writing a bridge converts a vendor concern into a permanent internal maintenance obligation for a capability PHP already provides. If the real requirement is "less getter/setter noise," the answer in 2026 is constructor promotion and readonly, not a 48-star archived Symfony bundle.