Laravel Support Laravel Package

Getting Started

This release is primarily a compatibility drop: 3.9.0 adds Laravel 13 support (#49). There are no API changes, no deprecations, and no breaking changes — the remaining commits are housekeeping (LICENSE year, README image, repository banner). If you are already on 3.x, this is a drop-in composer update.

Minimal steps:

composer require andrey-helldar/<package>:"^3.9"

1. Confirm the constraint resolves. If your composer.json pins laravel/framework to ^11 or ^12, nothing changes for you — 3.9.0 is still valid. If you are evaluating an upgrade to Laravel 13, this is the release that unblocks it, so bump both together rather than in separate PRs.
2. Look first at the package's service provider and config/ directory after install. Helldar packages conventionally ship a publishable config and rely on Laravel's package auto-discovery, so there is usually no manual providers entry needed. Verify with php artisan about or php artisan vendor:publish --provider=... if the config isn't appearing.
3. First use case: install it, run your test suite unchanged, and diff composer.lock. That single step tells you whether the Laravel 13 bump is actually safe in your app — which is the whole point of this release.

Implementation Patterns

Pin the minor, not the patch. Because this release line is stable and the project ships frequently, "^3.9" gives you the Laravel 13 compatibility without surprise majors. Avoid dev-master for production; the recent commits show an active CI/bot pipeline that rewrites README assets, and you don't want asset churn in your lockfile diffs.

Upgrade Laravel and this package in the same commit. The added value of 3.9.0 is entirely the widened framework constraint. Splitting the two into separate PRs means one of them will fail dependency resolution and you'll waste a cycle debugging a non-issue.

Treat the config file as the integration surface. Publish it once (vendor:publish) and commit it, rather than relying on runtime defaults. If the package reads config at boot, overriding via env() inside the package's own config is fragile under config:cache — put your values in your app's own config layer or in the published file directly.

Wire it into your test matrix before rollout. Add a job that runs the suite against Laravel 13 with this package installed, using an in-memory SQLite or your existing test DB. Since the release notes show no behaviour changes, a green suite is the strongest signal you'll get that the compatibility claim holds for your usage.

Watch the changelog, not the commits. This project's commit log is dominated by automated image/banner updates from github-actions[bot]. Filter on the Added / Changed / Deprecated headings in releases rather than watching the repository feed.

Gotchas and Tips

• "Laravel 13 compatible" ≠ "Laravel 13 only". The constraint was widened, so older framework versions remain supported. Don't assume you must upgrade Laravel to take this patch — but do confirm the exact illuminate/* range in composer.json before assuming Laravel 13 will resolve cleanly alongside your other dependencies.
• Dependency conflicts will surface here first. If a transitive package (a support library, a dev tool) hasn't widened its own constraints, composer update will fail with a helpful-but-noisy conflict tree. Use composer why-not laravel/framework 13.* to find the actual blocker instead of reading the full output.
• Cosmetic changes still touch your lockfile metadata. The LICENSE, README, and banner commits don't change behaviour, but a composer update will still move the reference hash. Review the diff and confirm only the version/dist reference moved.
• No deprecations means no migration work — but re-check your config. If you skipped earlier 3.x minors, run vendor:publish --force against a scratch copy and diff the config against yours; occasionally keys get renamed silently across minors and only surface at runtime.
• Debugging entry points: the package's service provider (registration/boot order), the published config file, and php artisan about for confirming the package is discovered. If behaviour is unexpected after the bump, composer show -t andrey-helldar/<package> reveals the resolved dependency graph.
• Extension points: Helldar packages typically expose interfaces/contracts and a config-driven driver or resolver. Bind your own implementation in a service provider rather than editing vendor code — this keeps you upgradeable across the frequent patch releases. Confirm the actual contract names in the README before relying on them.
• CI hygiene: if you mirror dependencies or run composer validate --strict, re-run it after the bump; widened constraints occasionally trip strict validation on your own composer.json platform requirements.