foodineers/laravel-devtools
A Laravel development toolkit offering helpful debugging and productivity utilities for local development. Install via Composer to gain quick insight into your application and streamline everyday build tasks.
v1.6.0 is effectively a breaking release for anyone who has already integrated the package — the root namespace moved to Foodineers. If you are installing fresh, you get the new namespace and can ignore the upgrade notes below; if you are upgrading, treat this as a major-version bump in spirit even though the tag reads as a patch.
Start here, in this order:
composer show foodineers/* (or the vendor/name in your composer.json) and verify the version and the PSR-4 mapping in the installed composer.json before writing any code.src/ and its service provider first. The provider tells you the binding name, whether a facade alias is registered, what config file is merged, and whether anything is publishable. That single file answers most "how do I call this" questions faster than the README, which may still contain pre-1.6.0 namespace examples.class_alias() calls or a legacy src/ subtree still mapped to the old namespace. If a shim exists you can upgrade lazily; if not, every use statement is now a hard error.A good first use case is the smallest possible one: publish the config (php artisan vendor:publish --provider="Foodineers\...\ServiceProvider" — the string form matters here, see Gotchas), resolve the package's main class out of the container in tinker, and make one real call. Doing this before touching application code isolates namespace problems from logic problems.
Resolve from the container, don't new it up. Packages that move namespaces usually do so as part of a broader refactor of the service provider. Constructor injection or app(Foodineers\...\Client::class) keeps you tied to the binding rather than to a concrete constructor signature, so provider-level changes in a future release don't break your call sites.
Wrap the package in a thin application-level adapter. Given that this release was a pure namespace churn, the highest-leverage pattern is a single App\Support\... class that is the only file importing Foodineers\.... Every consumer in your app depends on your adapter. The next namespace move becomes a one-file diff plus a composer dump-autoload.
Keep class-string config honest. If the package's config file has keys holding fully-qualified class names (drivers, handlers, formatters, model/morph maps), those are strings in a config file — static analysis and IDE refactors will not find them. After upgrading, grep the published config for the old namespace explicitly.
Test against the binding, not the class. In feature tests, $this->app->instance(Foodineers\...\Client::class, $fake) or $this->mock(...) keeps tests independent of the namespace. Better still, bind your adapter interface and fake that, so tests never mention the vendor namespace at all.
Pin the constraint. Use "^1.6" rather than "*" or a floating dev branch. A namespace relocation landing in a 1.x minor is a signal that this package's versioning is not strictly semver, so pin deliberately and upgrade on your own schedule.
CI integration. The "GitHub fix" means the release pipeline changed; re-run your own CI immediately after bumping rather than assuming the previous green build is still meaningful. Check that the tagged commit on GitHub actually matches what Packagist serves — a mismatch is the classic symptom of an Actions/packaging fix that landed mid-release.
use statements, docblocks and @param/@var annotations, string class references in config and arrays, event/listener discovery, factory and seeder references, and anything registered in a service provider with a literal string.class_alias bridge in place until the backlog drains. Same applies to failed-jobs payloads and any serialize()d cache entries.php artisan config:clear, php artisan cache:clear, and php artisan optimize:clear — cached config will happily serve the old provider/alias strings long after composer update. In production, confirm the deploy script clears config; this is the single most common "it works locally" cause after a namespace change.composer dump-autoload -o after editing anything autoload-related, and check composer.json for a leftover PSR-4 entry pointing at the old prefix. Stale optimized classmaps will throw "class not found" for classes that plainly exist on disk.app.aliases historically) and are easy to miss because they don't look like namespaces.replace / deprecated shim blocks in the package's composer.json. If the author kept the old namespace as an alias, you can migrate incrementally — but don't assume the shim will survive the next release. Note it as technical debt with a deadline.composer show, composer dump-autoload -o, php artisan config:clear, then php artisan tinker with class_exists('Foodineers\...'). If that last call is true but your app still fails, the problem is a cached config or a string reference, not autoloading.How can I help you explore Laravel packages today?