Twig Extensions Laravel Package

Getting Started

1. Install and confirm the version. composer require <vendor>/<package> then composer show <vendor>/<package> — you want ≥ 3.2.2 if your app runs on Laravel 5.6+ (Symfony 4 components).
2. Service provider / alias. Laravel 5.5+ package auto-discovery registers the provider for you. On older apps, add it to config/app.php and register the facade alias there.
3. Publish what you need. php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider" — only publish the config file; skip migrations/stubs unless you actually use them.
4. First use case. Resolve the package's main entry point from the container (app(SomeManager::class) or its facade) rather than new-ing it up — that's what wires in config, the HTTP client, and the Symfony-version-dependent collaborators. Start with the single feature you installed it for (e.g. dispatching a job, transforming a payload) and verify it in php artisan tinker before wiring it into a controller.

Implementation Patterns

• Constructor injection over facades. Bind the manager in a small service class and inject it; the facade is fine for quick scripts and tests, but constructor injection keeps the Symfony-version boundary in one place and makes the class mockable.
• Config-first. Almost every behavior is driven from config/<package>.php. Keep environment-specific values in .env and reference them from config (env('PACKAGE_DRIVER')) so you never edit published config per environment.
• Wrap it behind your own interface. Create a thin App\Contracts\X that the package class implements or that wraps it. Your app code then depends on your interface, and a future major (or a swap to a different package) becomes a one-file change.
• Queue integration. If the package dispatches work, keep its queue connection configurable and give it a dedicated queue (onQueue('package')) so a slow external dependency can't starve your default queue.
• Testing. Use the package's fake/shouldReceive hooks in setUp() and assert on the observable side effects (dispatched jobs, HTTP calls via Http::fake()) instead of asserting on the package's internals. Add one integration test that hits the real service provider boot so config mistakes fail in CI.

Gotchas and Tips

• 3.2.2 is a dependency-compatibility release, not a feature release. Its only change is allowing Symfony 4 (symfony/*: ^4.0) alongside Symfony 3. It's a safe patch upgrade — no API changes — but it does change the range composer will resolve.
• Watch the lockfile, not just the manifest. After upgrading, composer update --with-dependencies can pull in a different Symfony minor than the rest of your app expects. Run composer why symfony/console before and after to confirm you haven't split your Symfony component versions across two majors.
• On Laravel ≤ 5.5 you're still on Symfony 3. Don't force symfony/*: ^4.0 in your root composer.json to "take advantage" of this release — the framework itself will conflict.
• Clear caches after any composer change: php artisan config:clear && php artisan cache:clear. Stale cached config is the single most common cause of "it worked yesterday" after a package bump.
• Debugging failed resolution. If composer update reports a conflict, composer why-not <vendor>/<package> 3.2.2 pinpoints which dependency is holding you back — usually an older symfony/* constraint from a third-party package, not the framework.
• Extension points. Prefer binding your own implementation of the package's contracts in a service provider over forking the package for small tweaks; custom drivers, formatters, and HTTP middleware are all exposed via config in most packages of this shape.
• Pin it. Commit composer.lock and pin "<vendor>/<package>": "^3.2" so a future 4.x doesn't land silently in a routine update.