Laravel Uploader Laravel Package

Getting Started

• Require the package through Composer and confirm the resolved version is 3.4.x. The headline of this release is a widened framework constraint, so the first thing to verify is that composer show <vendor>/<package> reports 3.4.0 and that composer why-not laravel/framework 13.* returns nothing.
• If you are already on Laravel 13, 3.4.0 is the first line in this series that advertises support — treat it as the minimum version for an L13 application rather than an optional bump.
• If you are on Laravel 11 or 12, there is no forcing function here. Read the diff before upgrading: the release contains a single compatibility change (#42) and no feature work, so upgrading is low-risk but also low-value unless you are planning the framework jump.
• First place to look is the package's service provider and config/ directory after vendor:publish. Nothing in 3.4.0 suggests a renamed config key or provider, but a compatibility release is exactly when maintainers quietly relax type hints or bump a transitive dependency — confirm against the provider's register()/boot() signatures before assuming your existing wiring still binds.
• First use case to exercise: stand the package up in a scratch Laravel 13 app, hit the one or two code paths you actually depend on, and only then roll it into the real application. The maintainers' composer test passing is necessary but not sufficient evidence for your usage.

Implementation Patterns

• Constraint strategy. Keep your own require as ^3.4 rather than pinning 3.4.0. Compatibility releases like this one tend to be followed by patch releases that fix edge cases the widened constraint surfaces on the new framework major; you want those automatically.
• Upgrade the framework and the package in one PR. The value of a Laravel 13 support release is that it unblocks a framework bump. Splitting them into two PRs makes it ambiguous which change broke the build when something does.
• Run a real CI matrix. If you support more than one Laravel major, test the package against each (laravel/framework: ^12.0 and ^13.0 in a matrix job). The package's own suite passing on the maintainer's machine does not prove parity across framework versions.
• Isolate the upgrade behind your test suite, not behind manual QA. Since the release is a constraint change with no documented behaviour changes, your existing feature tests are the primary safety net. If coverage around the package's integration points is thin, add a smoke test before upgrading rather than after.
• Treat upstream style noise as upstream. The release notes flag pre-existing Pint failures in the repository. This is not a signal about code quality in the shipped artifact and should not gate your upgrade — but it does mean the project's CI is not fully green, so a red check on a follow-up release is not automatically a regression you caused.
• Watch the lock file. After upgrading, commit composer.lock and diff it. A framework-constraint relaxation sometimes pulls a newer transitive dependency into your tree, and that is the more likely source of surprise than the package's own code.

Gotchas and Tips

• "Supports Laravel 13" is a claim about constraints, not behaviour. The release notes document no code changes beyond the constraint. Verify the paths you rely on under L13 yourself; do not infer behavioural parity from a green test run.
• composer update may not move you. If the package is held back by another dependency, use composer update <vendor>/<package> --with-all-dependencies and read the solver output. composer why-not <vendor>/<package> 3.4.0 is the fastest way to find the actual blocker.
• Do not exclude vendor/ from Pint ad hoc to silence this. If your own pipeline reports style failures, check whether it is scanning dependencies — it should not be. The upstream Pint issues are irrelevant to consumers.
• No deprecations or breaking changes are announced in 3.4.0. That makes this a safe patch-level bump from a SemVer standpoint, but it also means there is no migration guide to lean on; your own changelog entry should record the framework-version decision, since that is the actual change you are making.
• Debugging a failure after upgrade: first re-run with the package pinned back to the previous 3.x release while keeping Laravel 13. If it still fails, the problem is the framework bump, not this release — a distinction that saves a lot of time.
• Extension points to re-check: published config, any registered facades or aliases, and event/listener wiring in the provider. A widened framework constraint occasionally coincides with relaxed return types that change what your subclasses and decorators must declare.
• Pin your CI PHP version deliberately. Laravel 13 raises the floor on PHP; if your matrix still includes an older runtime, the package may resolve but the framework will not. Confirm the PHP constraint before debugging anything else.