Input Select Laravel Package

Getting Started

Version 0.1.0 is the first public release, so treat this as an evaluation-grade dependency rather than something to build on. There's no upgrade history, no deprecation policy, and almost certainly no backwards-compatibility guarantee yet. The goal for the first week is not "integrate it" but "find out what it actually does and how easily it can be removed."

Where to look first, in order:

1. composer.json — check require for the PHP and illuminate/* constraints. A 0.1.0 package is often tested against a single Laravel version; if yours isn't in that range you're on your own.
2. The service provider in src/ — this is the real table of contents. It tells you what's bound in the container, what's published, what commands and facades exist.
3. README.md — usually the only documentation at this stage. Assume it's aspirational until you've run the code.
4. tests/ — if there are none, drop your expectations accordingly and budget time for your own integration tests.
5. CHANGELOG.md / tags — confirms 0.1.0 is genuinely the first tag and not a reset.

Minimal adoption steps:

# Pin exactly for the evaluation; do not use a caret range yet
composer require vendor/package:0.1.0

# If the provider isn't auto-discovered, register it manually
php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
php artisan package:discover

Then verify the wiring before writing any application code:

// tinker
app()->bound(Vendor\Package\SomeContract::class); // adjust to the real binding

First use case: pick a single, non-critical, read-mostly path — a report, a console command, an admin-only screen. Do not put it behind a customer-facing request or inside a queued job that can't be safely re-run until you've seen it behave under load and failure.

Implementation Patterns

Wrap it in your own boundary. This is the single most valuable pattern for a pre-1.0 dependency. Define an interface in your app, implement it with the package, and bind it in a service provider. When 0.2.0 renames a method, you change one adapter class instead of forty call sites.

// app/Contracts/ThingClient.php
interface ThingClient { public function fetch(string $id): array; }

// app/Adapters/PackageThingClient.php
final class PackageThingClient implements ThingClient { /* delegates to the package */ }

// AppServiceProvider
$this->app->bind(ThingClient::class, PackageThingClient::class);

Pin and lock. Use an exact version (0.1.0, not ^0.1 — though ^0.1 at least confines you to 0.1.x). Commit composer.lock. Treat every bump as a code review of the diff, not a routine composer update.

Gate it behind config. Add your own flag so the feature can be switched off without a deploy-time code change:

// config/services.php or a dedicated config file
'package_enabled' => env('PACKAGE_ENABLED', false),

Resolve the real implementation or a null/no-op implementation based on that flag.

Isolate in the container. Depend on interfaces and constructor injection rather than facades or app() calls. If the package ships a facade, use it sparingly — facades make it harder to see where the coupling lives, and harder to swap later.

Test doubles. If the package ships a fake or an in-memory driver, use it in tests. If not, your own adapter interface is the test double — that's another reason to have one.

CI matrix. Because 0.1.0 likely has narrow test coverage, run your own suite against the Laravel and PHP versions you actually deploy on. Pin the package version in CI so an unexpected resolution doesn't change your build.

Keep the blast radius small. Avoid using it in database migrations, one-shot data fixes, or anything that can't be re-executed. Early releases are where you find the edge cases that corrupt state.

Gotchas and Tips

• Pre-1.0 semver is not stable. By convention, 0.x minor bumps may break. A 0.2.0 can be a rewrite. Assume it will be.
• Auto-discovery may be absent. Check extra.laravel.providers in the package's composer.json. If it's missing, register the provider manually in bootstrap/providers.php (Laravel 11+) or config/app.php.
• Config publishing tags are guesses in early releases. Run php artisan vendor:publish interactively to see what tags actually exist rather than trusting the README. Then run php artisan config:clear — a stale cached config is the most common "it worked yesterday" cause.
• Read the diff, not the changelog. A changelog entry of "First Release" tells you nothing. When 0.1.1 lands, git diff 0.1.0..0.1.1 in the vendor repo is your only reliable upgrade guide.
• Verify extension points before designing around them. Events, macros, custom drivers, and config-driven overrides are frequently promised in a first README and only partially implemented. Confirm each one exists in the source before you commit architecture to it.
• Debugging basics: php artisan about for the discovered-package list, php artisan package:discover -v if the provider isn't loading, and a quick app()->bound(...) check in tinker before assuming an autoload problem.
• Watch the error surface. First releases tend to leak vendor exceptions and generic RuntimeExceptions. Catch and re-wrap at your adapter boundary so callers see your domain's error types.
• Have an exit plan. Before shipping, confirm you can remove the package by swapping your adapter implementation. If removal would require touching many files, the boundary isn't doing its job.
• Do not build core domain logic on it. Use it at the edges — integrations, formatting, tooling — until there's a 1.0 or at least a stable 0.x line with a track record.