Nova Radio Field Laravel Package

Getting Started

• Verify before you commit. The 0.1.0 release notes are a single line ("First release"), so there is no changelog, no documented feature set, and no upgrade guide to read. Treat the README and the src/ tree as the actual specification: start at the service provider (src/*ServiceProvider.php) to see what is bound into the container, then config/ and routes/ if present. That triad tells you more about day-to-day behaviour than the release notes do.
• Install behind a version pin. For a 0.x release, use composer require vendor/package:0.1.* rather than ^0.1. Under semver, anything below 1.0.0 may break in a minor bump, and with no migration notes published you want the upgrade to be a deliberate act.
• Publish only what you need. Run php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" without a tag first to list the available groups, then publish selectively (--tag=config, --tag=migrations). Copying everything into your app on a first release creates files you will have to diff by hand later.
• First use case: one isolated integration. Wire the package into a single feature — one controller, one queued job, or one console command — rather than spreading it across the app. Since the public API is unproven at this version, contain the blast radius so a 0.2.0 breaking change means editing one file, not fifteen.

Implementation Patterns

• Resolve through the container, not new. If the package ships a manager or client class, inject it or app() it. Constructor new calls bypass any bindings, config merging, and test doubles the provider sets up, and they are the single most common reason a package "works in tinker, fails in a job."
• Prefer contract/interface binding over concrete classes. If the package exposes an interface, bind your own fake to it in a test service provider rather than reaching into the package's internals. This is your only stable seam when the concrete classes are still churning.
• Keep configuration in config/ and read it once. Move any package options out of inline literals and into a dedicated config file (or config/services.php for credential-style values). Read them through config() at resolution time, not in a class constant — otherwise config:cache in production will silently serve stale values.
• Fake or swap in tests, don't hit the network. Where the package offers a fake, swap(), or a testing trait, use it; where it does not, bind a stub against its interface in setUp(). Assert on the calls you made rather than on internal state, so a refactor in 0.2.0 does not break your suite.
• Wrap side effects in your own layer. Put a thin application-level service in front of the package (e.g. App\Support\XClient) that your controllers and jobs talk to. When the package's API shifts, you change the wrapper and leave call sites untouched — this is the highest-leverage habit with any pre-1.0 dependency.
• Integration tips: if the package registers routes, check php artisan route:list for collisions with your own prefixes; if it registers migrations, run migrate on a throwaway database first and inspect the schema before it touches staging.

Gotchas and Tips

• 0.1.0 means "API not yet settled." Expect signature changes, renamed config keys, and moved namespaces in the next few minors. Pin the version, read the diff of every release before bumping, and do not build the package into a public extension point of your own app yet.
• Config caching will bite you. After changing package config, run php artisan config:clear locally; in production remember that config:cache during deploy means a config change requires a redeploy, not just a file edit. The same applies to route:cache if the package registers routes with closures — those cannot be cached and will fail the deploy.
• Autoload and discovery quirks. If the provider is not auto-discovered, check composer.json extra.laravel.providers in the package; if you have dont-discover set in your app, you must register it manually in bootstrap/providers.php (Laravel 11+) or config/app.php. A "class not found" on a package class after install is almost always composer dump-autoload.
• Debugging: php artisan about shows discovered packages; php artisan tinker plus app()->make(...) confirms bindings; Laravel Telescope's request and job watchers catch failures inside queued usage that never surface in HTTP logs. Add a Log::debug at your wrapper boundary rather than inside vendor code.
• Extension points to look for: macros (Macroable traits), custom drivers via a manager's extend(), publishable views, and events the package dispatches. These are the supported ways to customise behaviour; subclassing vendor classes is not, and it breaks silently on upgrade.
• No data was available to ground this assessment beyond the one-line release note. Before relying on any specific above, confirm the package actually ships a service provider, config file, and test suite — absence of tests at 0.1.0 is a meaningful signal about how much you should trust the API.