Initializer Bundle Laravel Package

Getting Started

Reality check first: this bundle is archived and last tagged in March 2015. It targets Symfony 2.x / PHP 5.x. Do not scaffold a new project on it — treat it as a reference implementation or something you'd vendor a single class out of. If you're a Laravel developer, translate the concepts (service container tags → Laravel service providers/tags, console command → Artisan command) rather than trying to bolt it into a Laravel app; there is no Laravel integration path.

Minimal steps in its native Symfony 2 context:

1. composer require presta/initializer-bundle and pin to the last release (~1.0) in the require block, not require-dev, if other bundles depend on it.
2. Register Presta\InitializerBundle\PrestaInitializerBundle in app/AppKernel.php.
3. Import the bundle's routing/config only if needed — the bundle is console-oriented, so usually you just need the bundle registration and any presta_initializer config block under config.yml.
4. Run app/console list presta (or list and grep for initializer) to confirm the command surface registered.

Where to look first, in this order:

• Command/ — the entry point you'll actually invoke; read the configure()/execute() to see what arguments, options, and output it emits.
• DependencyInjection/ (extension + Configuration.php) — the tag name used to register initializers and any config keys.
• Initializer/ — the interface/base class your own tasks must implement.
• Resources/config/services.xml — how the bundle itself wires things; copy this pattern for your own initializers.

First realistic use case: project bootstrap / post-deploy housekeeping. Things like "ensure web/uploads and app/cache exist and are writable", "generate a local parameters.yml from a template", "create the first admin user", "seed reference data". You register each as a small service, tag it, and run one command that executes them in order — instead of a pile of shell scripts in a Makefile.

Implementation Patterns

Tag-and-run registry. The core pattern is a tagged-service registry. You define a class implementing the bundle's initializer interface, register it as a service, and add the tag described in the bundle's Configuration/CompilerPass. The runner command collects all tagged services (usually via a compiler pass that builds an ordered collection, or by findTaggedServiceIds at runtime) and calls each one. Mirror this in Laravel by tagging services in a ServiceProvider::register() and injecting $app->tagged('initializers').

Ordering matters. Initializers that depend on each other (create directory → write template into it → chmod) need deterministic order. Use the tag's priority attribute if supported; otherwise the collection order in services.xml is your contract. Document the intended order in the service definitions, not in prose — that's the only thing future-you will read.

Idempotency as a design rule. Every initializer should be safe to re-run. In practice: check-then-create (if (!file_exists(...))), write only when content differs, and make the "already done" case a quiet success with a debug-level message rather than an exception. This lets you call the command from every deploy without fear.

Deploy-pipeline integration. Wire the command into your release script after composer install --no-dev and after cache warmup:

app/console cache:clear --env=prod
app/console presta:initializer:run --env=prod -n

Guard it so a failure aborts the deploy (set -e), and give it its own CI job step so the log is attributable.

Composer hooks for developer onboarding. A post-install-cmd / post-create-project-cmd script that invokes the initializer gets new contributors from git clone to working app in one step — this is the highest-value use of the bundle.

Environment-scoped initializers. Register dev-only initializers (fixtures, sample data, Xdebug-friendly permissions) in config_dev.yml's service imports so production runs never touch them.

Wrap, don't extend, if you're on modern Symfony. If you're maintaining a legacy app that still uses this, keep your initializer logic in plain services with no bundle dependency and let the bundle's tagged command be a thin adapter. That way, when you finally migrate the console command to a native Symfony command (or to Laravel's artisan), the actual work is untouched.

Gotchas and Tips

It's abandoned — pin hard. No security fixes, no PHP 7/8 compatibility work, and no Symfony 3+/4+/5+ support. Use an exact constraint and, ideally, a Composer replace/fork. Run composer why presta/initializer-bundle before upgrading anything; transitive removal is likely once you drop the dependent bundle.

Zero dependents on Packagist is the tell. Nobody is exercising the upgrade paths. Your integration bugs will be original research. Budget for reading the source rather than the (thin) docs.

Silent no-ops from tag typos. If your service isn't tagged exactly as the compiler pass expects, the command runs "successfully" and does nothing. When nothing happens: app/console container:debug --tag=<tag> (Symfony 2.6+) or debug:container to confirm your service is actually in the tagged collection. This is the single most common failure mode with tag-based registries.

Compiler passes run at cache build time, not run time. Adding a new initializer service without clearing the cache can leave the collection stale. Always cache:clear after touching service definitions, and remember cache:clear is per-environment — clearing dev doesn't clear prod.

Permissions are the classic failure. Initializers that mkdir/chmod run as the CLI user, which is usually not the web user. Directory permissions created by the command can be unwritable by www-data (or apache). Either drop group-write bits + setgid in the initializer, or run the command as the deploy user with a shared group.

-n and interactivity. If any initializer prompts (e.g., "admin password?"), -n in a deploy script will fail or take a default. Separate interactive bootstrap initializers from non-interactive deploy initializers at the config level rather than relying on flags.

Exit codes and partial failure. Decide up front whether a failing initializer aborts the rest. A registry that catches exceptions per-initializer will report success even when half the tasks failed — poison for CI. Prefer fail-fast with a clear "failed: " message, and expose -v/-vv verbosity for stack traces.

No dependency injection into execute() beyond constructor. These bundles are constructor-injection only (no autowiring era). Keep initializer constructors small; if an initializer needs ten collaborators, it's a workflow, not an initializer.

Testing. Test each initializer as a plain unit against a temp directory (sys_get_temp_dir() + cleanup in tearDown), and test the command once with a CommandTester to assert ordering and the aggregate exit code. Don't try to test the compiler pass through the full kernel — instantiate it and feed it a ContainerBuilder directly.

When to stop using it. The moment you need Symfony 3+, drop this and write a single app:init command. The bundle's value is the pattern (tagged services + one runner command), which is about forty lines of code you can own outright — with ordering, idempotency, and exit codes you actually control.