Pretty Routes Laravel Package

Getting Started

• Install with composer require andrey-helldar/<package>:^3.9 — 3.9.0 is the first line that declares Laravel 13 support, so pin at ^3.9 rather than accepting an older minor.
• Look here first: the package's composer.json. Confirm the illuminate/* constraints now include ^13.0 and check the php constraint — Laravel 13 raises the PHP floor, and a package that supports both 12 and 13 will typically require the higher of the two. Your app's PHP version must satisfy it before anything else works.
• Second stop: src/ServiceProvider.php (or src/Providers/). Helldar packages generally rely on Laravel package auto-discovery, so there should be nothing to register manually — verify the extra.laravel.providers block exists in composer.json before you go adding entries to config/app.php.
• Third stop: the config/ directory and the README's publish section. Most of these packages ship a config file you publish with php artisan vendor:publish --provider="...ServiceProvider".
• First use case: create a throwaway Laravel 13 app, install the package, publish its config, and exercise one real call path (a facade call, a helper, or whatever the README's headline example is). That single smoke test tells you more about 3.9.0's readiness than the changelog does, because the only change in this release is a compatibility declaration — the behaviour is identical to 3.8.x by design.

Implementation Patterns

• Treat 3.9.0 as a constraint bump, not a feature release. The sole change is Laravel 13 compatibility. Nothing new to wire up; your job is upgrade validation, not integration work.
• Upgrade path: bump the constraint, then composer update andrey-helldar/<package> --with-all-dependencies. Resolving the new illuminate/* constraint will likely force transitive updates across the framework packages, so use -W to avoid a half-resolved lockfile.
• Verify in your own suite, not in a scratch app. Because the diff is a composer.json constraint change, the risk surface is "does the package's internals still behave under Laravel 13's contracts" — exactly what your existing feature tests cover. Run them against 13 before merging the bump.
• CI matrix for apps that support multiple Laravel majors: add Laravel 13 as a matrix axis rather than replacing 12, and let the package's own constraint resolution pick the right version per job (composer require "laravel/framework:^13.0" --no-update inside the job, then composer update).
• For package authors depending on this one: use orchestra/testbench and test against 12 and 13. Keep the dependency in require (not require-dev) and mirror the widened constraint (^3.9) so downstream users aren't blocked from Laravel 13 by your package.
• Keep config in config/ + env, not inline in code. Publish the config once, commit it, and drive environment-specific values through .env. This survives framework upgrades far better than passing options at call sites.
• Resolve through the container. Where the package exposes a facade or a concrete class, inject it (or bind an interface to it in a service provider) rather than calling the facade statically in domain code — it keeps your tests fast and makes a future swap or a wrapper straightforward.

Gotchas and Tips

• Framework-support bumps are often shipped as a patch or minor. 3.9.0 carries no documented breaking change, but a constraint widening can still break you if your lockfile was resolving to an older illuminate/* set. Read composer.lock's diff after updating, not just the changelog.
• PHP version failure mode. If composer update fails with a platform conflict, it's almost certainly the PHP floor (Laravel 13 requires a newer PHP than 12). Check php -v against the package's require.php before assuming a package bug.
• Stale caches after upgrade. Run php artisan config:clear && php artisan cache:clear in any environment using config:cache. A cached config from the pre-upgrade deploy plus a widened constraint is a classic "works locally, fails in staging" source.
• Auto-discovery is easy to miss in debugging. If the package appears inert, check php artisan about and bootstrap/cache/packages.php — the provider should be listed there. If not, discovery is disabled or the package wasn't re-installed after the bump.
• Don't hand-register providers or aliases that the package already auto-discovers; duplicates cause double-registration and confusing side effects.
• Check the test suite runs green on Laravel 13 upstream. The release note credits a single contributor (#88) for the compatibility work; a glance at the repo's CI matrix tells you whether the claim is backed by an actual 13 job or was merged on a constraint edit alone. That distinction is your real risk signal.
• Watch for the next release. If 13-support landed as a minor, the following 3.10.x likely tightens or drops older framework support. Subscribe to the repo's releases if you're carrying a long-lived app on Laravel 11/12.
• Extension points remain the same as 3.8: published config, container bindings, and any documented macros/listeners. This release adds none, so any 3.8-era customisation you've written should carry over unchanged — and if it doesn't, that's a regression worth reporting rather than something to patch around.