kanuuu/eloquence-mappable
Eloquence Mappable adds a trait to Laravel Eloquent models for mapping attributes and relationships to custom array and JSON keys, so you can shape clean API output without exposing database column names.
Version 6.0 is the Laravel 6 compatibility release, and the major version bump is the important signal here: the package now aligns its versioning with the framework. Assume ^6.0 targets Laravel 6.x only and that Laravel 5.5–5.8 support has been dropped.
Minimal path to a first working call:
composer require vendor/package:^6.0
php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
php artisan config:clear
Then verify the wiring before writing any real code:
php artisan tinker
>>> app(Vendor\Package\Manager::class)
Where to look first, in order:
composer.json of the package — check require (PHP constraint, illuminate/* constraint) and extra.laravel.providers / extra.laravel.aliases. If discovery is declared, you do not need to register the provider in config/app.php, and doing so creates a double registration.config/package.php — every default you will want to override lives here.register()/boot() — tells you what is bound as singleton vs. transient, which determines whether state leaks between requests and jobs.First use case to smoke-test: a single synchronous call through the facade or injected manager inside a feature test, driven by the published config with test-specific values, so you confirm config resolution, container binding, and credentials in one shot.
Prefer constructor injection over the facade inside your own classes. The facade is fine in controllers and Blade, but resolving from the container is what makes the package swappable in tests and keeps you honest about the singleton bindings.
public function __construct(private Vendor\Package\Manager $manager) {}
Treat config as the integration layer. Publish once, commit config/package.php, and drive environment differences through env() only at the config file level — never call env() from application code, because Laravel 6's config:cache will silently return null for those calls in production.
Wrap the package behind your own thin service. A app/Services/YourWrapper.php that delegates to the package manager gives you one place to add logging, retries, and caching, and one place to change when you eventually swap or upgrade the package. This is the single highest-value pattern for a dependency you did not write.
Queue anything that touches the network. If the package performs I/O, call it from a job rather than a request cycle, and set explicit $timeout and $tries on the job. In Laravel 6, retryUntil() on the job is the clean way to bound retries by wall clock instead of attempt count.
Test with RefreshDatabase plus a fake or a bound stub. Bind a fake implementation in the container in setUp() rather than hitting the real backend:
$this->app->instance(Vendor\Package\Manager::class, new FakeManager());
If the package ships a ::fake() helper, prefer it — it usually also asserts the calls you made.
Use the manager's extend() if it exposes a driver pattern. Custom drivers registered via extend() in a service provider survive config:cache; closures registered at runtime in a controller do not, and will break in production.
^6.0 installs alongside Laravel 5.8. On an app mid-upgrade, run composer why-not vendor/package ^6.0 to see the exact conflicting constraint rather than guessing from the error message.str_slug(), array_get(), camel_case(), etc., they will fatal. Either add laravel/helpers or move to Str::slug() / Arr::get(). Audit the published config file and any published views for this specifically.php artisan config:clear after touching the published config locally, and re-run config:cache in deploy. A stale cached config is the most common cause of "it works in tinker but not in the app."vendor:publish now needs --force. Re-publishing after an upgrade is often the fix for a changed config schema, but it silently overwrites local edits. Diff before forcing.UPGRADE.md/CHANGELOG.md diff between the last 5.x tag and 6.0 — if none exists, pin the exact version in composer.json until you have run your test suite against it.config('package')) and check app()->bound() for the manager before assuming a package bug. If the package logs, ensure your config/logging.php channel actually has the level set — Laravel 6 defaults to debug in single but your production stack may drop it.extend() on a driver manager, and any Macroable trait on the manager. These are the three ways to change behaviour without forking.How can I help you explore Laravel packages today?