Flux Radial Laravel Package

Getting Started

jonpurvis/radial is a small, single-maintainer Laravel package now at v1.1.0. The only change in this release is Laravel 13 compatibility, so treat the upgrade as a compatibility bump rather than a feature release — nothing in your existing v1.0.0 usage should need rewriting.

Minimal steps:

1. composer require jonpurvis/radial — on Laravel 11+ the service provider is auto-discovered; there is no manual providers entry to add in bootstrap/providers.php.
2. Publish any shipped config/assets before touching code, so you have a file to diff against on the next upgrade:

   php artisan vendor:publish --provider="JonPurvis\Radial\RadialServiceProvider"
   

   (Check the README for the exact --tag= value; if the package ships no publishable assets this step is a no-op.)
3. Confirm the resolved version: composer show jonpurvis/radial should report v1.1.0 and a framework constraint that includes ^13.0.
4. Where to look first, in order: the README usage section → src/ (the package surface is small enough to read end-to-end in one sitting) → config/ → tests/ for the canonical usage examples the maintainer actually exercises.

First real use case: drop it into a fresh Laravel 13 skeleton and run the README's primary example plus php artisan test. That single loop validates the whole v1.1.0 release for your environment faster than reading the changelog.

Implementation Patterns

Pin and upgrade deliberately. Because v1.1.0 is additive, the practical workflow is: bump the constraint in composer.json, run composer update jonpurvis/radial --with-dependencies, then run your suite. If you are still on Laravel 11/12, staying on ^1.0 is fine — but there is no reason to, since the minor adds a framework constraint rather than changing behaviour.

Wrap it, don't sprinkle it. The package has a narrow surface and one maintainer. Put the calls you depend on behind a thin app-level service or Blade component of your own:

// app/Support/Radial.php
final class Radial
{
    public function render(array $options = []): mixed
    {
        return /* the package entry point you actually use */;
    }
}

This costs an hour and buys you a one-file migration if the package stalls or the API shifts in a future major.

CI matrix. Add Laravel 13 to the matrix alongside your current versions rather than swapping it in. The maintainer's own CI is the only thing standing behind the compatibility claim, and a two-version matrix in your pipeline is what actually protects you.

Blade vs. PHP usage. If the package exposes a facade and a Blade directive/component, standardise on one per project. Mixing them makes it hard to see where the dependency lives when you later audit it.

Testing. If the package ships fakes or an assertion helper, register them in TestCase::setUp() so failures point at your code, not at the package's internals. If it does not (likely, at this size), keep your integration tests at the boundary — assert observable output, not internal state.

Gotchas and Tips

• This is a minor release — but verify the constraint actually widened. Some maintainers ship "Laravel 13 support" as a composer.json edit only. Check the published require block; if it still caps at ^12.0, the tag landed without the change that matters.
• PHP floor moves with the framework. Laravel 13 raises the minimum PHP version. If your app is on an older PHP in production but a newer one in CI, you will pass locally and fail on deploy. Check php -v on every environment before rolling this out.
• Dependency-resolution conflicts. If another package in your tree still caps at laravel/framework: ^12.0, composer update will quietly keep you on radial v1.0.0. Use composer why-not jonpurvis/radial 1.1.0 to see exactly which package is holding you back.
• Bus factor of one. v1.1.0 is the maintainer's first contribution to the repo per the release notes, and the project is two releases old with no prior assessment history. That is not a reason to avoid it — it is a reason to keep the wrapper above and avoid depending on undocumented internals.
• No changelog depth to lean on. The release notes contain one line. There is no migration guide because nothing needs migrating. Do not go looking for a v2 upgrade path that does not exist yet.
• Lock file discipline. Commit composer.lock in applications. For a package at this maturity, an unpinned transitive surprise is more likely than a bug in radial itself.
• Debugging. With no dedicated debug tooling, the fastest diagnostic is php artisan tinker against the package's entry point to confirm it resolves from the container at all — a surprising share of "package is broken" reports are auto-discovery or config-cache issues (php artisan config:clear after publishing).