Discord Webhook Laravel Package

Getting Started

This release (1.3.0) is a compatibility release: the only stated change is Laravel 13 support. There are no new features, no deprecations, and no documented breaking changes, so day-to-day usage is unchanged from 1.2.x — the work is in verifying the constraint and re-testing your integration points.

Minimal steps:

1. Confirm the constraint actually moved. Check composer.json in the package for illuminate/support, illuminate/contracts, and any Laravel-adjacent dependencies now allowing ^13.0. If the package only widened the constraint but your app is still on 12.x, nothing changes for you.
2. Upgrade in a branch: composer require vendor/package:^1.3 then composer update vendor/package --with-dependencies. Watch for transitive pins (composer why-not vendor/package 1.3.0) — a stale lockfile or a sibling package still capped at ^12.0 is the most common reason the bump silently fails.
3. Re-publish nothing by default. Run php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" --tag=config only if you need to diff against your existing published config (see Gotchas).
4. Clear caches: php artisan config:clear && php artisan cache:clear && composer dump-autoload.
5. First use case: pick your single most important code path that touches this package — the one command, job, or endpoint that exercises its main API — and run it end-to-end in a fresh Laravel 13 app before touching your production codebase. Treat that as the go/no-go gate.

Where to look first in the package source: composer.json (constraints and PHP floor), the service provider's register()/boot() (what gets bound and auto-discovered), and config/*.php (the public surface you're most likely to have customised).

Implementation Patterns

Constrain explicitly, don't float. In application composer.json, prefer "vendor/package": "^1.3" over "*". A compatibility release is exactly the moment where an unpinned dependency can drag you onto a major Laravel bump you didn't plan for.

Resolve from the container, never new. Whatever the package binds — a manager, client, or repository — inject it via constructor or app() so the package's own bindings, config merging, and test doubles keep working across framework versions. Code that instantiates package classes directly is the code most likely to break on a Laravel major.

Keep configuration in config/ and read it through config(). Never read the package's env vars directly; Laravel 13's config caching behaviour is the same contract, and bypassing it produces values that differ between php artisan serve and a cached production deploy.

Upgrade workflow for a compatibility release:

branch → bump constraint → composer update → run package's own migrations (if any)
→ run your test suite → run the smoke path → deploy to staging → prod

Do this as a standalone PR. Bundling a framework-support bump with feature work makes bisecting a regression needlessly hard.

Test against the real framework version. Use orchestra/testbench (or your app's phpunit.xml) pinned to the Laravel 13 line for this branch, and keep a CI matrix that still runs Laravel 12 while you support both. Feature tests that boot the package's service provider catch auto-discovery and binding regressions that unit tests miss.

Use the package's fakes/doubles where offered. If it ships a facade with ::fake() or a swap-in test double, prefer that over hitting real external services — this also insulates your tests from internal changes the maintainer might make while adding framework support.

Integration points to re-verify on any Laravel major: queued jobs that serialise package objects (SerializesModels behaviour), event/listener wiring registered in boot(), scheduled tasks registered via Schedule, and any custom validation rules or Blade directives the package registers.

Gotchas and Tips

• Published config and migrations do not auto-update. vendor:publish writes a copy into your app; a package upgrade will not refresh it. After bumping, diff the package's config/ and database/migrations/ against your published copies. Silent config drift is the single most common cause of "it worked in a fresh install but not in ours".
• "Laravel 13 support" does not mean "identical behaviour on 13". The constraint may have been widened after minimal testing. Check the package's CI matrix on the tagged commit — if there's no Laravel 13 job, treat the support as provisional and lean harder on your own smoke test.
• Check for a raised PHP floor. Framework majors usually move the minimum PHP version. If the package's composer.json now requires a newer PHP than your servers run, composer update will fail in CI but succeed locally on a newer machine — verify your deploy target's PHP version, not just your laptop's.
• Auto-discovery can be disabled. If your app's composer.json has extra.laravel.dont-discover, the provider won't register and you'll get "target class does not exist" or null bindings after the bump. Confirm the provider is still listed in bootstrap/providers.php (Laravel 11+ style) if you register manually.
• Facade docblocks and IDE helpers go stale. If the package ships a facade, regenerate _ide_helper.php after upgrading, and re-run static analysis (Larastan/PHPStan) at your highest level. Deprecation notices surfaced by a framework major are cheapest to fix now, before the next major removes them.
• Watch deprecations as failures. If your test suite converts deprecations to errors (recommended), expect the Laravel 13 branch to surface warnings from the package's internals. Distinguish package-sourced deprecations (report upstream, pin a workaround) from your own (fix immediately).
• Debugging aid: php artisan about shows the resolved Laravel version, and composer show vendor/package shows the installed tag plus its declared requirements — the fastest way to confirm you're actually running 1.3.0 and not a cached autoload.
• Extension points to re-check: container bindings you override in your own provider, config keys you've republished and edited, and any class you've extended from the package. These are the surfaces a compatibility release is most likely to have touched without saying so in a one-line changelog.
• If you're mid-upgrade on your app, sequence it as: upgrade the app to Laravel 13 first on the current package version, confirm green, then bump this package. Doing both simultaneously leaves you unable to tell which change broke what.