sgcomptech/filament-ticketing
Filament Ticketing adds a complete helpdesk and ticket management system to Filament panels. Teams can create, assign, prioritize, and track tickets, organize conversations, and manage statuses, making it easy to bring structured support workflows into Laravel applications.
This release is a compatibility sync rather than a feature drop: 1.3.0 aligns the package with Laravel 10. Treat your first task as confirming a clean install on a Laravel 10 app before you build anything on top of it.
Minimal path:
composer.json.composer require your-vendor/package:^1.3 --with-all-dependencies
The --with-all-dependencies flag matters here — a Laravel 10 sync usually widens illuminate/* constraints, and without it Composer can hold the whole tree back to Laravel 9.composer.json first, not the README. On a "sync with Laravel 10" release, the constraint block is the actual changelog: you want illuminate/support: ^10.0, php: ^8.1, and a orchestra/testbench: ^8.0 in require-dev. If illuminate/* still caps at ^9.0, the tag is mislabeled — stop and open an issue.php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" --tag=config
php artisan package:discover
php artisan config:clear && php artisan route:clear && php artisan view:clear
Stale bootstrap/cache/packages.php from a Laravel 9 install is the single most common false negative after a version bump.Where to look, in order: composer.json (constraints), UPGRADING.md/CHANGELOG.md (breaking notes), the service provider (what's bound, what's deferred), then the config file (what's actually tunable).
Verify the sync with a dependency-matrix check, not a smoke test. The release note tells you the package claims Laravel 10 support. Prove it by running the app's test suite against laravel/framework:^10.0 in isolation, and keep a ^9.0 || ^10.0 job in CI as long as you support both. A package that synced by widening constraints without touching its own tests can pass composer update and still fail at runtime.
Pin the minor, float the patch. Use "your-vendor/package": "^1.3" in composer.json and commit composer.lock. Because 1.3.0 is a compatibility release, 1.3.x patch releases are the most likely place for follow-up fixes to the Laravel 10 work — you want those flowing in without a review cycle.
Staged rollout across environments. Sequence the upgrade as: local → CI → staging → production, running php artisan about on each to confirm the framework version actually reported matches what you intended. Deploy the lockfile change as its own commit so a rollback is a single git revert rather than an archaeology exercise.
Isolate the package behind your own boundary. Rather than calling its facade or classes from twenty places, wrap the primary interaction in a small service class or a dedicated job. Laravel 10 syncs frequently come with signature changes (native return types, dropped $dates property, dispatchNow() removal); a one-file boundary turns a package-wide refactor into a one-method edit.
Queue and event integration. If the package dispatches events or jobs, register listeners in EventServiceProvider rather than relying on the package's own auto-registration, and confirm ShouldQueue behaviour on your configured queue connection. Serialization of package models across queue boundaries is the classic place a framework bump bites — payloads serialized under Laravel 9 may not deserialize cleanly on 10 if the package's models changed shape.
Test with the package's own assertions. Most Laravel packages ship Package::fake() and Package::assertX() helpers. Prefer those over mocking internals — they're the surface the maintainer keeps stable across framework syncs, and they're what protects your tests on the next major bump.
Config over code. Anything the package exposes in config/package.php (drivers, endpoints, retry counts, queue names) belongs in config/ or .env, not in a hardcoded constructor argument. When 1.3.x lands a driver fix, you want to change an env var, not a class.
The 8.0 → 8.1 jump is the real breaking change. "Sync with Laravel 10" is shorthand for "requires PHP 8.1." That means readonly properties, pure intersection types, and first-class callable syntax are now available — and also that any transitive dependency still capping at php: ^8.0 will block the install. Run composer why-not php 8.1 when resolution fails; it names the blocker directly instead of making you read conflict walls.
Laravel 10 removed things packages commonly leaned on. If the package was synced quickly, watch for lingering use of dispatchNow() (use dispatchSync()), the $dates model property (use $casts), Bus::dispatchNow, and assertTimesSent in tests. These fail loudly, which is good — but they fail at runtime, not install time, so a green composer update proves nothing.
Column-change migrations need doctrine/dbal no longer — but old code may assume it. Laravel 10 dropped the DBAL requirement for change(). If the package's migrations or your own use ->change() with DBAL-specific assumptions, verify rather than assume.
Config cache is a trap during upgrade. php artisan config:cache bakes env values at build time. If the package reads config in a service provider's register() and you cache config before setting the new env keys, you get silent nulls in production only. Always config:clear after changing package env vars, and prefer env() only inside config files.
Auto-discovery cache outlives the upgrade. If the package appears installed but its facade throws "class not found," delete bootstrap/cache/packages.php and services.php and re-run php artisan package:discover. This is the highest-frequency false alarm on any version bump.
Check the service provider's defer flag. Deferred providers only load when a bound service is resolved. A Laravel 10 sync that changes deferred bindings can produce "works in tinker, fails in queued job" symptoms, because the resolution order differs. Test through a real request and a real queued job, not just php artisan tinker.
Deprecations are the trailing indicator. PHP 8.1 and 8.2 emit deprecation notices for strlen(null), dynamic properties, and ${var} string interpolation. If 1.3.0 was a minimal sync, the package may still emit these. Turn E_DEPRECATED into a visible log channel in staging for one release cycle — the next major version will almost certainly make them errors.
Debugging technique when the failure is opaque: re-run the failing path with php artisan tinker calling the package's entry point directly. If it works in tinker but fails in the request lifecycle, the problem is provider registration or config caching, not the package. If it fails in both, it's the sync itself — check the package's GitHub issues filtered to laravel-10 before debugging further, since compatibility gaps are usually reported within days of a tag.
Extension points to prefer: publish and edit the config file, bind your own implementation over the package's interface, and use its events rather than subclassing its concrete classes. Subclassing a class the maintainer is actively editing for framework compatibility is how upgrades turn into merges.
How can I help you explore Laravel packages today?