Laravel Rateable Laravel Package

Getting Started

This release is a compatibility bump: the package now declares support for Laravel 12. Nothing new to learn API-wise, so the fastest path is to confirm your constraints line up and re-run your existing test suite.

1. Check the constraint change first. Open composer.json in the package and compare illuminate/* / laravel/framework ranges against the previous tag. The 3.5.0 diff is likely a one-line widening (e.g. ^10.0|^11.0 → ^10.0|^11.0|^12.0) plus a matching orchestra/testbench bump. That single diff tells you whether your app can upgrade or whether a transitive dependency is still blocking you.
2. Confirm your runtime. Laravel 12 requires PHP 8.2+. If your app or CI image is still on 8.1, resolve that before touching composer.
3. Upgrade the package, not the framework, in isolation. Run composer update <vendor>/<package> --with-dependencies on your current Laravel version first. If 3.5.0 still supports 10/11 (it should, given the widening), you get the patch with zero framework risk and can defer the Laravel 12 move.
4. First use case: boot the app, hit one route/service that exercises the package's main integration point, and run php artisan about to confirm the framework version the app actually resolved. Most breakage from a version-support bump shows up at container binding or service-provider registration time, not in your feature code.

Implementation Patterns

Treat the version constraint as a feature flag. Because 3.5.0 is additive (Laravel 12 added, older versions retained), you can sequence the upgrade: package first, framework second. This gives you a bisectable failure point if something breaks — you'll know whether it's the package's Laravel 12 path or your own app code.

Widen your CI matrix before you widen your constraint. Add a Laravel 12 job (with orchestra/testbench ^10 for package tests) to your pipeline while your app is still on 11. Run it as non-blocking for one cycle. This is where you'll discover hardcoded illuminate/support versions in dev dependencies, PHPUnit/Pest version conflicts, and static-analysis baselines pinned to Laravel 11 stubs.

Pin exact versions in composer.lock, float in composer.json. Standard practice, but it matters more here: a support-widening release is exactly the kind of tag that gets pulled in by a routine composer update on a Friday. Lock the upgrade to a deliberate PR.

Pair the package bump with a framework bump in the same PR only when you have coverage. If the package is a thin integration layer (service provider, facade, a couple of config keys), the combined upgrade is usually trivial and one PR is cheaper than two. If it touches the HTTP kernel, queue, or Eloquent internals, split it.

Watch the config-publish path. If 3.5.0 changed anything under config/, your already-published config file will not pick it up. Diff vendor/<vendor>/<package>/config/*.php against config/<package>.php and decide whether to re-publish or hand-merge. Re-publishing overwrites local edits — copy the file aside first.

Integration tip: in multi-package monorepos, update all illuminate/* constraints in one commit. Partial widens produce resolver deadlocks that surface as opaque composer why-not output rather than clear errors.

Gotchas and Tips

• "Laravel 12 support" is not "Laravel 11 unsupported." Read the constraint before assuming a breaking change. If 3.5.0 dropped 10 or 11, that is the breaking change and it belongs in your upgrade notes, not the Laravel 12 migration.
• illuminate/* components can drift from laravel/framework. A package that constrains illuminate/support directly may still fail on a Laravel 12 app if a sibling package pins an older component. Diagnose with composer why-not laravel/framework 12.* — it names the actual blocker, which a plain composer update error will not.
• Carbon 3 is the quiet killer. Laravel 12 moved to Carbon 3, which changes some date-diff return types and sign conventions. If this package does any date arithmetic or exposes date objects, test those paths specifically rather than trusting a green smoke test.
• Deprecation noise ≠ failure. Laravel 12 raises deprecations that some packages surface as warnings in logs. Confirm whether they originate in the package or your app before filing upstream; a support-bump release rarely fixes them.
• orchestra/testbench version is the tell. Testbench 10 ↔ Laravel 12. If the package's dev dependencies still point at Testbench 9, its Laravel 12 support is declared but untested upstream — treat it as best-effort and lean on your own coverage.
• Clear caches after upgrading. php artisan config:clear && php artisan cache:clear — stale compiled config referencing old package paths or provider lists is a common and confusing post-upgrade symptom.
• Extension points to re-verify: container bindings, published config keys, and any facade accessors. These are the surfaces a version-support release is most likely to have touched incidentally, and the least likely to be covered by a changelog line that says only "Laravel 12 support."
• Debugging tip: if the package silently no-ops on Laravel 12 rather than erroring, check for version_compare or app()->version() guards in the source. Support-widening releases sometimes leave behind version gates that were never updated.