Maker Bundle Laravel Package

Getting Started

Because this package has no dependents and its last release was mid-2022, treat it as a reference implementation you copy from rather than a long-term dependency. Confirm it still installs against your Symfony version before building anything on it.

Minimal steps:

1. Require it alongside the maker bundle it extends:

   composer require --dev survos/maker-bundle
   

   It is a maker bundle, so it belongs in require-dev unless you plan to generate at runtime.

2. Register the bundle if Flex does not do it for you. Check config/bundles.php for Survos\MakerBundle\SurvosMakerBundle and add it manually for older skeletons.

3. Discover the commands it contributes:

   php bin/console list make
   

   Look for the make: commands that are not part of stock Symfony MakerBundle. Those are the package's surface area.

4. Where to look first: the generated output, not the source. Run one generator against a throwaway entity and read the controller and Twig files it writes. The templates are the real documentation — the README is thin and the code is the spec.

5. First real use case: scaffold an admin CRUD screen for an existing Doctrine entity. Generate the controller, generate the template, wire a route, and load it in the browser. If the scaffolded page renders, the package is doing its job for you; if not, you have learned early that the templates assume a front-end stack you do not have.

Implementation Patterns

Generate-then-own. The healthy pattern with any maker bundle is: generate once, commit the output, then stop depending on the generator. The generated controller and templates become ordinary application code you edit freely. This insulates you from the package's staleness.

Pair it with the admin stack it targets. Survos bundles generally assume a Bootstrap/Tabler-style admin theme and often a datatable layer. If your project already uses survos/bootstrap-bundle or a similar theme bundle, the generated templates will drop in cleanly. If you use EasyAdmin or Sonata, expect to rewrite the Twig rather than reuse it.

Use it as a CRUD scaffold, not a runtime framework. The value is the first 80% of a controller — index/show/new/edit/delete actions, form handling, redirect-after-save, flash messages. Generate it, then extend with your authorization voters, filters, and custom queries.

Layer your own base controller. If the generated controllers extend a Survos base class, keep that class thin and put your shared behavior (pagination defaults, audit logging, tenant scoping) in your own abstract controller that the generated ones extend instead. This prevents the generated code from calcifying around a dependency you may later drop.

Template override pattern. If the bundle ships Twig templates under a templates/bundles/... path, override them in your app's template directory rather than editing vendor files. Symfony's bundle override convention works here regardless of how stale the package is.

Iterate the generator for repeatable screens. Once you have generated three admin screens, extract the parts you keep rewriting into your own project-local maker command. At that point you have absorbed the package's idea and no longer need it.

Gotchas and Tips

Staleness is the headline risk. Last release June 2022, four stars, zero dependents. Expect incompatibilities with current Symfony minor versions, PHP 8.3+, and newer MakerBundle APIs. Pin your Symfony version or vendor the generated output early. Do not put this on a critical path.

MakerBundle API drift. Maker bundles subclass AbstractMaker and rely on internal MakerBundle helpers that change between minor releases. If make commands vanish from list make or throw Class not found, the cause is almost always a MakerBundle version mismatch, not your config. Check the required constraint in the package's composer.json and align.

No dependents means no community debugging. Search results for errors will be empty. Debug by reading the generator source directly — it is small — and by comparing generated output against what stock make:controller produces.

Template assumptions are invisible until runtime. Generated Twig may reference CSS classes, JS assets, or blocks from a theme bundle that is not installed. A rendered page with unstyled markup or a missing block error means you need the companion theme, not a code fix. Grep the generated templates for asset(, encore_entry, or stimulus references before assuming it will just work.

Check what it writes before it writes it. Run generators with --dry-run if supported, or generate into a scratch branch and diff. Some maker commands append to routes.yaml or overwrite existing templates without prompting.

Bundle registration is easy to forget. Flex recipes for low-traffic packages are often absent or stale. If commands do not appear, verify config/bundles.php first, then clear cache (bin/console cache:clear) — maker command discovery is cached in some setups.

Extension points to prefer. If you must stay on the package, extend its maker classes or its base controller rather than editing vendor code, and override Twig via the standard bundle override path. If the package offers configuration under survos_maker: in config/packages/, read the bundle's Configuration.php — that file, not the README, is the accurate list of knobs.

Exit strategy. Given the score and age, decide up front whether you are adopting or harvesting. If harvesting, copy the generated controllers and templates into your app within the first hour, remove the dev dependency, and move on. That is likely the highest-value way to use this package today.