do6po/tentacles
do6po/tentacles is a Laravel/PHP package that adds flexible, reusable functionality to your application through a simple, expressive API. It integrates cleanly with Laravel's container and configuration, making setup and customization straightforward.
What this release means for you: v1.0.5 is a compatibility release — it adds support for Laravel ^9. There are no new features, deprecations, or documented breaking changes in the notes, so the practical impact is that the package can now be installed in Laravel 9 applications (and that an upgrade path exists if you are moving an app from Laravel 8 to 9).
Minimal steps:
^8.0. Before touching the package, verify php -v and that your composer.json require.php constraint is ^8.0 or higher.composer require <vendor>/<package>:^1.0 — then inspect composer.lock to confirm you resolved to 1.0.5 and not an older 1.0.x that lacks the Laravel 9 constraints.composer.json (in vendor/<vendor>/<package>/composer.json) for its illuminate/support, illuminate/contracts, and orchestra/testbench constraints. That file — not the release note — is the authoritative statement of what the package actually supports.config/app.php.php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>" and review the published file before running php artisan migrate.First use case: the lowest-risk way to validate the upgrade is to install v1.0.5 into a new, empty Laravel 9 app, exercise the package's headline feature once (a single facade call, a single job dispatch, or one console command), and only then attempt the upgrade in your real application. This isolates "does it boot under Laravel 9 at all?" from "does my app's integration still work?"
Pin and stage the upgrade. Treat this as a dependency bump, not a feature adoption. Use a branch with composer require <vendor>/<package>:1.0.5 --with-dependencies, run your test suite, and diff composer.lock to see whether the package dragged in transitive changes to illuminate/*, symfony/*, or nesbot/carbon.
Resolve the package through the container, not new. Whatever the package exposes — a client, manager, repository, or driver — bind it in a service provider and inject it. This is the pattern that survives version bumps, because a constructor signature change becomes a one-line fix in your binding rather than a search-and-replace across the codebase.
// app/Providers/AppServiceProvider.php
public function register(): void
{
$this->app->singleton(\Vendor\Package\Client::class, function ($app) {
return new \Vendor\Package\Client(
config('package.api_key'),
config('package.endpoint'),
);
});
}
Wrap it in your own thin adapter. For day-to-day leverage, define a small application-owned interface (App\Contracts\Thing) with one implementation that delegates to the package. Calls to the vendor API then live in exactly one file. When a future release changes behaviour, you patch the adapter and the rest of the app is untouched.
Configuration through config/ only. Never read credentials or endpoints inline. Publish the package config, then override values via .env and your own config/package.php. Keep a config('package.*') grep as part of review — it makes environment drift obvious.
Testing pattern. Use RefreshDatabase if the package ships migrations, and Http::fake() / Queue::fake() / Event::fake() around package calls so your tests assert on your dispatch, not the vendor's HTTP. For a Laravel 9 upgrade specifically, add one integration test that boots the provider and resolves the package's main binding from the container — that single test catches most provider/version regressions.
CI matrix. Add an explicit laravel/framework:^9.0 job (e.g. via orchestra/testbench:^7.0) alongside your existing Laravel 8 job. Because v1.0.5 exists specifically to widen framework support, the matrix is the artifact that proves it works for you.
^9 excludes Laravel 10 and 11. The stated constraint is ^9, not >=9. If your roadmap includes Laravel 10+, expect to be pinned to 1.0.x or blocked until a later release widens the constraint. Check the package's composer.json to see whether it is ^9.0 (Laravel 9 only) or ^9.0|^10.0.v1.0.5. The typical Laravel 9 enablement patch touches composer.json constraints and may also swap removed/deprecated APIs, so the diff is short but load-bearing.$dates property on models (use $casts), str_*/array_* helpers in favour of Str::/Arr::, and the old Symfony\Component\HttpFoundation\File\File behaviours. If the package's Laravel 9 support was achieved by constraint-widening alone, deprecation warnings may still surface at runtime — run with APP_DEBUG=true and check storage/logs/laravel.log on first use.php -v before debugging anything else; a confusing composer update conflict is almost always a PHP constraint two levels down.php artisan package:discover (or composer dump-autoload) and check bootstrap/cache/packages.php. A cached manifest from the previous version is a classic "it installed but nothing works" cause — clear it with php artisan optimize:clear.config/*.php against your published copy; missing keys silently resolve to null rather than erroring.$this->app->bind(...) in a provider registered after it), and its events/listeners. Avoid subclassing vendor classes or reaching into vendor/ — those are the things a future release will break without warning.php artisan tinker (app(\Vendor\Package\Client::class)) before assuming your application code is at fault. Container resolution failures point at the provider/composer constraint; successful resolution followed by a runtime error points at an API or behavioural change inside the package."<vendor>/<package>": "1.0.5" (or ^1.0.5) rather than ^1.0, so a composer update doesn't silently pull a 1.0.6 that you haven't reviewed — given the sparse release notes, unreviewed patch bumps carry unnecessary risk for a package whose changes you cannot read about ahead of time.How can I help you explore Laravel packages today?