Nova Artisan Cards Laravel Package

Getting Started

Important caveat up front: the v0.1.0 release notes contain no changelog, feature list, or upgrade guidance — just a version tag. Everything below is a baseline workflow for evaluating and adopting any Laravel package at 0.1.0, and should be verified against the package's own README and source before you commit to it in production.

Minimal steps:

1. Install with an explicit stability flag. 0.1.0 is pre-1.0, so a default composer require vendor/package will fail on a stable-only project:

   composer require vendor/package:0.1.0 --with-all-dependencies
   

   Pin the exact version — not ^0.1 — until you've read the source.
2. Read the service provider first. It is the map of the package: container bindings, merged config, publishable assets, registered commands, and event listeners. Find it under vendor/vendor/package/src/.
3. Publish what's publishable, then review it before committing:

   php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
   

   Prefer tagged publishes (--tag=config, --tag=migrations) so you can re-publish selectively later.
4. Check what package:discover registered. php artisan about and php artisan package:discover will confirm the provider loaded; if not, it's usually a composer.json extra.laravel.providers issue.
5. First use case: run the package against its own defaults in a scratch route or php artisan tinker session before wiring it into a real feature. With no release notes, the default config is the de facto documentation for what 0.1.0 does.

Implementation Patterns

Resolve from the container, never new. Early packages almost always ship a binding that reads config; instantiating directly bypasses it and will break the moment the constructor signature changes:

public function __construct(private PackageManager $package) {}

Put a thin adapter in front of it. For a pre-1.0 dependency this is the single highest-value pattern — one app-level class or interface wrapping every call site, so a breaking change in a 0.x minor becomes a one-file fix instead of a grep across the codebase.

Keep the package's config in config/ and secrets in .env. Do not scatter package env keys through your own config files; 0.1.0 config keys are not stable and will move.

Fake what it dispatches. Depending on whether the package talks HTTP, queues jobs, or fires events, pair it with Http::fake(), Queue::fake(), or Event::fake() in tests. Because you can't trust a 0.1.0 API surface, assert on your adapter's behaviour, not the package's internals.

Bind and swap in tests. If the package exposes an interface, bind a fake in a test service provider rather than hitting the network or a real driver:

$this->app->instance(PackageClient::class, new FakePackageClient());

Migrations deserve a decision. Determine whether migrations are publishable (you own them, can edit them) or auto-loaded (they run on every migrate and you cannot change them). If auto-loaded, check they're guarded against duplicate table creation before running them against an existing database.

Gotchas and Tips

• 0.1.0 is not a semver promise. Expect breaking changes in 0.2.0. Pin exactly, and treat every minor bump as a potential major.
• Diff before you upgrade. With no changelog, the only reliable upgrade path is composer update vendor/package followed by a git diff of vendor/vendor/package/ (or diffing the two tags on the package's repo). Vendor the diff review into your release checklist.
• Version constraints are often narrow on early releases. Check the package's composer.json for php and illuminate/* ranges — a 0.1.0 frequently pins a specific Laravel major and will silently constrain your own framework upgrades.
• Stale config cache. After changing any package env var: php artisan config:clear. A cached config is the most common cause of "the package ignores my settings."
• Provider not loading? Re-run composer dump-autoload and php artisan package:discover. In Octane or queue workers, restart the workers — long-lived processes don't pick up new bindings.
• Extension points, in order of preference: package events you can listen to → container bindings you can override → published config → published views/migrations → macros. Editing vendor/ is never an option; it disappears on the next composer update.
• The missing changelog is itself the finding. A 0.1.0 published without release notes suggests the API is still in flux and documentation is unfinished. Budget time for reading source, and avoid adopting it for anything load-bearing until you've seen a 0.1.x or 0.2.0 release that does document its changes.