Contenttools Bundle Laravel Package

Getting Started

• Install with composer require <vendor>/<package>:^1.0. Version 1.0.1 is the first release explicitly compatible with Symfony 5.0 components, so prefer ^1.0.1 over ^1.0.0 when your app pulls in Symfony 5.
• Check the package's composer.json constraints first: you want php >=7.2.5, symfony/*:^5.0, and a Laravel framework version that can resolve alongside Symfony 5 (Laravel 6+ in most projects). Run composer why-not <vendor>/<package> 1.0.1 if the install fails.
• Publish any config and migrations:

  php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
  

• First use case: resolve the package's main service from the container rather than instantiating it directly. Most Laravel integrations expose a manager or factory that is already bound in the service provider:

  $manager = app(\Vendor\Package\Manager::class);
  

• Where to look first, in order: the README's "Installation" section, the package service provider (to see bindings and tags), the published config/<package>.php, and the package's own test suite under tests/. The tests are the most reliable documentation of how the Symfony 5 integration is meant to be used.

Implementation Patterns

• Constructor injection over facades. Bind the package contract in your own service provider or rely on auto-resolution, then inject it into controllers, jobs, and console commands. This keeps you testable and avoids the static facade in code that also runs inside queued jobs.
• Config-driven behaviour. Keep environment-specific values in config/<package>.php and reference them with env() only at the config layer. After changing config in a deploy, run php artisan config:clear and php artisan cache:clear.
• Wrap third-party calls behind your own adapter. If the package wraps Symfony 5 components (console, process, mailer, etc.), create a thin application-level interface. When the next Symfony major lands you change one adapter rather than every call site.
• Queue and CLI workflows. For long-running queue workers and Artisan commands, resolve the package per-job rather than once at boot. Symfony 5 component state (e.g. process handles, console input) is not always safe to reuse across jobs.
• Testing. Use the package's testing helpers if provided; otherwise swap the binding in the container with a fake in setUp(). Add an integration test that boots the full Laravel app so the Symfony 5 wiring is exercised, not just your unit mocks.
• CI matrix. Pin one job to the lowest supported Symfony 5.x and another to the latest 5.4 LTS. This catches both the "too old" and "too new" dependency problems that a compatibility bump like 1.0.1 is meant to solve.
• Upgrade workflow. When bumping the package, run composer update <vendor>/<package> --with-dependencies, then php artisan about and your test suite. Commit the lock file changes with the version bump so the compatibility fix is traceable.

Gotchas and Tips

• Symfony 5 is not a drop-in for 4.x. 1.0.1 adds Symfony 5 support, but if you were previously on Symfony 4 the package may have dropped 4.x support in the same release. Check the constraint in its composer.json before assuming your Laravel 6 app can still use it.
• Dependency conflicts are the usual failure mode. If composer require reports a conflict, it is almost always symfony/* or a transitive dependency pinned to 4.x. Use composer why symfony/console to find the culprit rather than forcing versions with --ignore-platform-reqs.
• Clear caches after upgrading. Laravel's compiled config, route, and view caches can retain stale class references after a package bump. Run php artisan optimize:clear before debugging "class not found" errors.
• Watch for deprecation notices. Symfony 5 removed several 4.x classes. If you extended a package class directly, you may get Class not found at runtime even though the container resolves fine. Prefer the documented extension points (config, events, bound interfaces) over subclassing.
• Debugging: enable the package's log channel or use Log::debug() around its entry points, and check storage/logs/laravel.log. If a service is not resolving, dump the container binding with app()->bound(...) and inspect php artisan tinker.
• Version pinning: in composer.json, pin "<vendor>/<package>": "^1.0.1" with a caret, not an exact version, so patch releases with further Symfony 5 fixes are picked up. Avoid dev-master in production.
• Extension points: the package service provider's register() and boot() methods, its published config, and any dispatched events are the supported hooks. If 1.0.1 changed constructor signatures in the name of Symfony 5 compatibility, resolve through the container so you are insulated from those changes.