Card Extended Laravel Package

Getting Started

Pull the package into a Nova app with Composer:

composer require cloudstudio/card-extended

Then look in two places before wiring anything up:

1. vendor/cloudstudio/card-extended/src/ — find the card class (e.g. CardExtended) and read its component(), constructor, and any with* config methods. This is a small, low-traffic package; the source is the real documentation.
2. vendor/cloudstudio/card-extended/resources/js/ — the Vue component tells you exactly which props it consumes, which is the contract you're actually programming against.

Register it like any Nova card in app/Nova/NovaServiceProvider.php:

use Cloudstudio\CardExtended\CardExtended;

public function cards(Request $request)
{
    return [
        (new CardExtended())->width('full'),
    ];
}

First use case: drop it on the Main dashboard as a dashboard card, confirm the card renders in the browser, then progressively pass props/config until it does what you actually need. Don't try to extend it before you've seen it render once.

Implementation Patterns

As a dashboard card. The lowest-friction pattern — instantiate in cards() and treat it as a standard Nova metric-style card. Good for surfacing custom widgets on Main.

As a base class for your own card. If the package exists to "extend" Nova's card, the intended pattern is usually to subclass it and override the component or inject additional props:

class MyMetricsCard extends CardExtended
{
    public function component()
    {
        return 'my-metrics-card';
    }
}

Verify in the source whether component() is overridable or hard-coded; if it's hard-coded, wrap it instead of extending.

Detail-view integration. Place the card in a resource's cards() method and pass the model context through the constructor or a ->withX($value) chain so the card can scope its data to the current record.

Composition over extension. Given the package's size, the most durable workflow is to use it as a rendered shell and pass your own data as props — keep business logic in a Nova metric/controller and let this card be presentational. If you find yourself patching the vendor's Vue component, fork it into nova-components/ instead.

Gotchas and Tips

• Verify it actually does what the name implies. With 9 stars and 0 dependents, the README may be aspirational. Read the compiled dist/js/card.js to confirm feature parity with the description before committing to it in a client project.
• Nova version compatibility is the big risk. Nova cards break silently across major versions (tool vs. card API, Nova::script vs. Vite). Check the package's nova/laravel/nova constraint in composer.json against your installed version; an unpinned constraint is a red flag.
• Recompile after edits. If you fork or patch the Vue source, run npm run dev/prod inside the package — Nova loads the compiled asset, not your .vue changes.
• Asset registration failures look like blank cards. A card that renders nothing is usually a missing Nova::script() call or a mismatched component name between PHP component() and Nova.component(...). Check the browser console before assuming a data problem.
• Width and layout. Always set ->width(...) explicitly (1/3, 1/2, full) — Nova's grid will stretch a card unpredictably otherwise, especially once multiple cards share a dashboard.
• No refresh/polling unless documented. If the card doesn't expose a refresh interval, don't assume reactivity; wire a LoadingCard or manual reload path yourself.
• Treat it as unmaintained. No dependents and a tiny star count means no community safety net. Pin the version in composer.json, and if it becomes load-bearing, vendor the source into nova-components/ so a future Nova upgrade doesn't strand you.
• Extension points are wherever the constructor accepts arguments. Grep the class for public function with and setters — those are your only sanctioned hooks. Anything else is a patch waiting to be overwritten on composer update.