Laravel Unique Sluggable Laravel Package

Getting Started

This assessment is reconstructed from the package's release history; v0.4.0 is a framework-compatibility release ("added Laravel 9&10 support") rather than a feature release, so the workflow below is anchored on installation, discovery, and upgrade verification. Confirm specifics against the package README and src/ before relying on any named API.

• Why this release matters: v0.4.0 is the compatibility gate. If you are running Laravel 9 or 10 and were previously pinned to an older tag, holding a fork, or using a dev- branch to get the framework to resolve, you can now use an upstream tagged release. That alone makes 0.4.0 the first version worth adopting on a modern app.
• Install: composer require vendor/package:^0.4. Note the caret semantics on a 0.x package — ^0.4 allows 0.4.x only and will not pull 0.5. If you want to float, say so explicitly; if you want stability, pin 0.4.*.
• Verify discovery first: after install, run php artisan package:discover (or just php artisan about on L9/L10) and confirm the service provider is listed. If the package does not use auto-discovery, register the provider manually in config/app.php — and only there.
• Where to look first, in order: (1) composer.json in the package for require/require-dev constraints and the extra.laravel block, which tells you what auto-registers and what is publishable; (2) the service provider for bindings, publishes, and migrations; (3) config/ inside the package for the published config file; (4) the CHANGELOG/UPGRADING files, which are the authoritative source for whether 0.4.0 carries anything beyond the framework bump.
• First use case: install into a fresh Laravel 10 app, publish anything publishable (php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"), run any shipped migrations, then exercise the package's primary entry point inside php artisan tinker or a single feature test before wiring it into application code. Getting one green path end-to-end on L10 is the whole point of this release.

Implementation Patterns

• Treat 0.4.0 as the new floor. Once you've validated it on L10, raise the constraint in every app that consumes the package and let CI prove it. Avoid leaving apps split across 0.3 and 0.4 unless they are on genuinely different framework majors.
• Upgrade sequence that works: bump the constraint → composer update vendor/package --with-all-dependencies → php artisan config:clear && php artisan route:clear && php artisan view:clear → re-publish config only if the shipped config file changed (diff the vendor copy first) → run the test suite. Do not vendor:publish --force reflexively; it will silently overwrite your local config edits.
• CI matrix, not trust. Test against both Laravel 9 (PHP 8.0–8.2) and Laravel 10 (PHP 8.1–8.3) if you ship to both. A package constraint satisfying Composer is not the same as a package working at runtime, and this release is precisely where that gap would show up.
• Isolate the package behind one seam. Wrap calls in your own service, interface, or adapter class. On a 0.x package the public API can move in a minor release; one adapter class is a cheap insurance policy and makes a future 0.5 bump a one-file change.
• Configure in the app, never in vendor. Publish config into your app's config/ directory and commit it. Overrides belong in .env if the package reads env, otherwise in the published file. Vendor edits vanish on the next composer install.
• Migrations belong in your deploy pipeline. If the package ships migrations, run them as an explicit step with a tested rollback, not implicitly during a request or a seeder.
• Lockfile per app. If you maintain several applications, keep separate composer.lock files and let each float independently; don't try to force one shared constraint across apps on different Laravel majors.

Gotchas and Tips

• 0.x semver is not 1.x semver. ^0.4 caps at <0.5, and by convention a 0.x minor bump may contain breaking changes. Pin exactly in production and upgrade deliberately; do not assume the next release is safe.
• Removed and deprecated APIs between L9 and L10. If you came from an older Laravel major, check for doctrine/dbal-dependent column modifications, removed Str/Arr helpers, and the PHP 8.1 baseline. The package supporting L10 does not mean your code around it does.
• Double registration. A classic failure mode: the provider was registered manually in config/app.php under an older setup, and the new version also auto-discovers. You get duplicate bindings, doubled event listeners, or duplicated routes. Remove the manual entry.
• Stale cached config in production. The single most common "works locally, breaks in prod" cause with any config-driven package. php artisan config:cache must be re-run on deploy, and config:clear before debugging.
• Publish tags over providers. Prefer --tag= when the package defines tags; --provider= can pull in more files than you intended and overwrite unrelated assets.
• Debugging the install itself: if composer require won't resolve, run composer why-not vendor/package 0.4.* to see exactly which dependency is blocking, and composer show vendor/package --all to list available versions and their framework constraints.
• Extension points to prefer: published config, container bindings (swap implementations by rebinding in your own service provider), and any events the package dispatches. These are the stable seams. Subclassing internal classes or reaching into vendor/ is the path to a painful upgrade.