Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Devtools Laravel Package

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.

View on GitHub
Deep Wiki
Context7

Getting Started

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:

  1. Confirm what you actually have installed. Release tags and Packagist syncs can drift, and the accompanying "GitHub fix" suggests CI/packaging changes around the same tag. Run 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.
  2. Open the package's 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.
  3. Check for a compatibility shim. Look for 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.

Implementation Patterns

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.

Gotchas and Tips

  • The namespace move is the whole release. Budget for a mechanical but wide sweep: 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.
  • Serialized queued jobs are the silent killer. Jobs already sitting in Redis/database queues contain the old fully-qualified class name if they hold a reference to a package class. Deploy the upgrade with an empty queue, or keep a class_alias bridge in place until the backlog drains. Same applies to failed-jobs payloads and any serialize()d cache entries.
  • Clear everything. 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.
  • Verify the facade alias. If a facade was previously registered under a short alias, check whether the alias string changed too. Facade aliases are registered in config (app.aliases historically) and are easy to miss because they don't look like namespaces.
  • IDE and static analysis lag. Regenerate IDE helper/indexes and clear PHPStan/Psalm result caches; a stale index produces phantom errors on the new namespace and can mask real ones.
  • Check for 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.
  • Debugging checklist when a class "doesn't exist": 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.
  • Extension points remain the provider and the config file. If you need to swap behaviour, prefer rebinding in your own provider over editing published config, and re-publish rather than hand-merge if the config schema changed alongside the namespace.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core
nodisrupt/laravel-agent
sierratecnologia/media-manager