Lilaconceptsbestpracticebundle Laravel Package

Getting Started

This is a Symfony 2.1 bundle, not a Laravel package. Treat it as a reference implementation and scaffold, not a runtime dependency. The single most valuable move is to clone it locally and read it as a "here is what a well-structured, tested, CI-backed bundle looks like" document.

Minimal steps:

1. git clone https://github.com/lilaconcepts/lilaconceptsbestpracticebundle somewhere outside your app — do not composer require it into a Laravel project (the Symfony 2.1 constraints will fight your framework).
2. Read in this order:
   • composer.json — package name, autoload PSR-0/PSR-4 mapping, require-dev (PHPUnit, Symfony).
   • LilaconceptsBestPracticeBundle.php — the bundle class itself (thin, as it should be).
   • DependencyInjection/ — the Extension and Configuration classes; this is the pattern most Laravel devs need to internalize.
   • Resources/config/services.yml — service wiring.
   • Tests/ — split into Unit/ and Functional/, plus the Tests/Fixtures/ kernel used by functional tests.
   • phpunit.xml.dist and .travis.yml — the test-runner and CI scaffolding.
3. First use case: fork it, rename it, and use it as the skeleton for a new bundle (or, for Laravel, copy the directory layout and test/CI files into packages/vendor/name/ and adapt).

If you're a Laravel dev who has to touch a legacy Symfony app, this bundle doubles as a Rosetta Stone: every concept here has a direct Laravel analogue (see below).

Implementation Patterns

Bundle registration (Symfony side). The bundle is inert until added to app/AppKernel.php:

$bundles = [
    // ...
    new Lilaconcepts\BestPracticeBundle\LilaconceptsBestPracticeBundle(),
];

Day-to-day, once registered, you interact with it through the container and Twig — not by instantiating classes.

DI Extension pattern → Laravel ServiceProvider analogue. The DependencyInjection/*Extension.php loads YAML service definitions and merges/prepends config; the Configuration.php defines the config tree (defaults, validation, env vars). This is the exact job of a Laravel ServiceProvider::register() + config/packages/*.php file. When porting a pattern to Laravel, map:

Service wiring. Define services in Resources/config/services.yml, inject dependencies via constructor arguments, and let the container autowire where the Symfony version allows. Prefer constructor injection over $container->get() calls; the latter is the fastest way to make a bundle untestable.

Twig extension pattern. If the bundle exposes template helpers, look at how a TwigExtension is registered as a service tagged twig.extension. The Laravel mirror is a Blade directive or a view composer.

Functional test workflow. The Tests/Fixtures/ mini-app (kernel + config) is the important trick: functional tests boot a real kernel and issue requests via WebTestCase. Copy this harness when you build your own bundle. Run with:

composer install
vendor/bin/phpunit

and mirror the same command in CI so local and remote stay aligned.

Fork-and-rebrand workflow (most common day-to-day use).

1. Fork, then globally rename the vendor namespace and bundle class (Lilaconcepts\BestPracticeBundle → YourVendor\YourBundle) with sed/IDE refactor.
2. Update composer.json (name, autoload, require-dev) and the phpunit.xml.dist bootstrap path.
3. Add the bundle to your app kernel and confirm bin/console boots without a container error.
4. Replace the Travis config (see Gotchas) and push — the CI badge becomes your safety net as you add code.

Integration tip. Keep your bundle thin and additive: services, a Twig extension, one or two commands. Don't let the bundle reach into app-level config; expose configuration via Configuration.php and let the app opt in. Same discipline you'd apply to a Laravel package that shouldn't call app() everywhere.

Gotchas and Tips

• It is not a Laravel package. Do not composer require it into a Laravel project. Symfony 2.1 constraints (symfony/* ~2.1, old PHPUnit, PHP ~5.3/5.4) will conflict with modern framework versions and Composer will either fail or drag in ancient transitive deps. Use it as source material only, or install it inside a throwaway Symfony 2.1 VM if you must run it.
• Symfony 2.1 is long EOL. Security fixes, PHP 7/8 compatibility, and modern PHPUnit are all absent. If you're forking for real work, budget time to modernize the CI and test bootstrap (PHPUnit config schema, setUp signatures, deprecations).
• Test bootstrap is the #1 breakage point. Functional tests need an autoloadable kernel under Tests/Fixtures/; if you rename namespaces and forget to update the fixture kernel's registerBundles() and the phpunit.xml.dist bootstrap path, tests fail with a confusing "class not found" rather than a meaningful assertion error.
• Naming conventions are load-bearing. The bundle class must end in Bundle, live in the namespace declared in composer.json, and match the directory name. The DI extension alias is derived from the bundle name (underscore-cased) — if services aren't being found, check the alias in getAlias() first.
• .travis.yml is dead weight now. Travis CI is effectively retired for new OSS. Replace it with a GitHub Actions workflow: shivammathur/setup-php, composer install --prefer-dist, vendor/bin/phpunit. Keep the same test command so local/CI parity holds.
• Config merging quirks. Configuration.php tree-builder defaults silently win over what you think you passed. When a config value "isn't taking effect," dump the processed container config (bin/console config:dump-reference / debug:container) before touching YAML.
• Template override location. If the bundle ships Twig templates and you need to change one without forking, override under app/Resources/<BundleName>/views/. Getting the path wrong is a silent fallback to the bundle default — verify the resolved path in the profiler.
• Debugging tools differ from Laravel. No artisan, no dd(), no Tinker. Use bin/console debug:container, debug:router, the web profiler, and var_dump + exit in a pinch. For Laravel devs this is the steepest day-one adjustment.
• Extension points worth knowing. Compiler passes (CompilerPassInterface) for conditional service wiring, service tags for opt-in behavior, and bundle inheritance for template overrides. These are the seams to use instead of editing bundle internals — the same reason you'd write a Laravel macro instead of patching vendor code.
• Read the README before the code. The bundle's entire value proposition is "this is how it should be laid out," so the prose explains why the structure exists. Skipping it and reading only classes loses the point.