Nova Greeter Laravel Package

Technical Evaluation

Architecture fit. oriondevelops/nova-greeter is a Laravel Nova dashboard card — a PHP class extending Laravel\Nova\Card that hydrates a Vue component into Nova's dashboard grid. It lives entirely in the presentation layer: no migrations, no publishable config, no scheduled jobs, no domain logic, no auth or permission changes. From a delivery standpoint this collapses scoping to a single binary gate: does this product run a licensed Nova installation, and do we want a greeting affordance on the admin dashboard? If yes, it is a self-contained UI unit that can be added or removed with a one-line revert. If no, the package has zero transferable value and should be closed out of the evaluation immediately rather than carried in a backlog.

Integration feasibility. The mechanical work is roughly half a day end-to-end including code review and a visual verification pass: one composer require, one entry returned from NovaServiceProvider::cards() (or a specific dashboards() definition if we scope per dashboard), an optional php artisan nova:publish, and a hard-refresh check. There are no data dependencies and no cross-team coordination surface beyond the platform owner who controls Nova. A TPM should treat the engineering task as effectively pre-solved and reallocate their attention to the actual product question: what does this panel do for the user, and is it a standalone nicety or the anchor for onboarding content we intend to build on.

Technical risk. Functional risk is low — the worst realistic outcome is a card that renders blank, which is cosmetic and recoverable. The risks that actually belong on a TPM's radar are delivery and governance risks:

• Nova compatibility drift. Nova is commercial and closed-source, and its card internals and Vue toolchain have shifted across majors (3 → 4 → 5). This package has a single release (v0.0.3, December 2024) from one maintainer. The open question is whether the composer.json Nova constraint covers the version we run today and the version we plan to upgrade to. A card built against Nova 4 can install cleanly and render nothing on Nova 5.
• Maintainer concentration / bus factor of one. 8 stars, 0 dependents, single author, one release, no downstream usage to shake out bugs or document behavior. The planning assumption should be explicit and written down: no upstream fixes for our environment, ever. The code is the documentation; our engineers will read src/NovaGreeter.php and resources/js/components/Card.vue to determine the actual configurable prop surface, because unrecognized meta keys are silently discarded.
• Supply-chain and security review. A Composer package runs in our build pipeline and, through compiled JS, inside privileged admin sessions. Before install we need answers to: are there any outbound network calls (telemetry, weather, geolocation) from the Vue surface; is the compiled asset deterministic and reproducible; and does a near-zero-adoption dependency pass our provenance bar. For an 8-star package, the review cost may legitimately exceed the cost of writing the card in-house.
• Configuration surface is undocumented and implicit. Config is passed through withMeta([...]) and only keys declared in the Vue props array survive hydration. That means any stakeholder requirement ("show their first name," "say good afternoon") is dependent on prop names a maintainer never documented.

Key questions to resolve before approval:

1. Which Nova major version(s) are we on today, and what is the committed upgrade timeline? Does the package's constraint cover both?
2. Is the greeting cosmetic only, or is it a beachhead for onboarding checklists, release notes, or role-specific quick links? (If the latter, the decision flips to build/fork.)
3. Does the card compute the time-of-day salutation client-side from browser time? If so, is timezone drift across a distributed admin user base acceptable, or do we need a server-computed greeting via meta?
4. What is our user-model reality — do SSO/provisioned accounts have a populated name, and who owns the fallback (display_name ?? email)?
5. Will this pass security/procurement review, and who is accountable for the fork if review fails?

Integration Approach

Stack fit. The package is a native Nova card and therefore only fits a stack that already includes Laravel + a licensed Nova installation at a compatible major version. There is no framework-agnostic path and no version that works without Nova. Confirming the Nova license and version is the first gate, not an afterthought — this card should never be a factor in a Nova licensing decision, only a beneficiary of one already made.

Migration path. There is essentially no migration: no schema changes, no data backfill, no config publication, no queue or scheduler wiring. The only state is whether the card is registered and what meta we pass. That gives us an unusually clean adoption/rejection symmetry — deletion is one array entry plus a composer update, with no migration to roll back and nothing else built on top of it. We should preserve that property deliberately: do not build anything on this card that we could not delete without a migration. Any requirement that would violate this is the signal to fork.

Compatibility. Two axes matter:

• Nova major version. Verify the constraint with composer show oriondevelops/nova-greeter --all and compare against our installed Nova. If it does not cover our major, or does not cover the next major we intend to move to, the correct posture is to vendor/fork the source rather than depend on it. Pin the exact version in composer.json regardless.
• Laravel/PHP and the Vue build toolchain. Nova's compiled-asset pipeline has changed across majors; verify the card's compiled assets load under our Nova build (php artisan nova:publish, then a hard refresh) rather than trusting a clean composer require as evidence of a working render.

Sequencing. I would sequence this as a low-risk, time-boxed spike rather than a feature:

1. Gate (day 0, ~1 hour): confirm Nova license/version and the package's Nova constraint. If either fails, stop — do not proceed to install.
2. Source review (day 0–1): read the card class and Card.vue props; grep resources/js for fetch|axios|http to confirm no outbound calls. This is the security review and the requirements-feasibility check in one pass.
3. Install & register in a non-production environment (day 1): composer require with a pinned version, register in cards() as ->width('full') at the top of the main dashboard, nova:publish, hard refresh. Verify it renders.
4. Verify the two known data edge cases (day 1): null name on SSO accounts (fallback via meta, not by editing vendor code) and timezone behavior of the salutation.
5. Scope and gate (day 1): decide whether to gate with canSee so service accounts and shared admin logins don't see a greeting addressed to a role, not a person. Consider per-dashboard scoping so it appears only on the main dashboard, not admin-only ones.
6. Ship to production, then hold (day 2+): release behind normal deploy, watch for blank-card reports, and record the fork decision point.

Decision checkpoint after step 3: if any requirement beyond "greeting strip" surfaces — CTA, onboarding checklist, release notes, activity summary, role-specific quick links — stop depending on upstream at that moment and scaffold with php artisan nova:card acme/greeter, copying Card.vue into our own card. A greeter is small enough to reimplement in an hour, and doing so eliminates the compatibility-drift risk entirely. Treat adoption as reference implementation, not strategic dependency.

Operational Impact

Maintenance. Steady-state maintenance cost is near zero if and only if we pin the version and treat the package as frozen. The maintenance burden is not in the card itself; it is in the two events that will eventually touch it: (a) a Nova major upgrade, and (b) a user-model change that alters the name field. Both are our responsibility, not upstream's. Assign explicit ownership — a named team, not "the platform team generally" — for the vendored/forked copy and for the visual re-verification on every Nova upgrade. Plan to fork on first need rather than filing an upstream issue; with a bus factor of one and no dependents, an upstream fix has no expected arrival time.

Support. There is no community backstop: 8 stars, 0 dependents, one maintainer, one release. Internal support load should be modeled as first-line support is us, with the vendor source as the reference. Practically, this means documenting the fork point in the runbook and keeping the two vendored files (NovaGreeter.php, Card.vue) readable to any engineer on the team. Because the card is a pure view, first-line triage for "my greeting is wrong/missing" is genuinely tractable: check canSee gating, check the name fallback, check whether a stale asset manifest is at play.

Scaling. The card has no scaling dimension to speak of — it is a per-session Vue component with no data access, no queries, no cache, no external calls (pending the grep confirmation). It will not affect dashboard latency or throughput at any realistic admin user count. The "scale" concern here is organizational, not technical: the number of Nova dashboards and the number of distinct audiences (ops, support, content, admin-only views) grows, and each one is a placement decision. Prefer a second card class gated by canSee() over stuffing conditionals into meta, so that Nova's card system owns routing and visibility and the greeter stays a pure presentational component. Keep the greeter out of admin-only dashboards.

Failure modes and triage. Ranked by likelihood:

• Blank card (most likely). Almost always stale assets, not PHP. Triage: devtools for a failed /nova-api request or missing compiled JS, then php artisan nova:publish, clear browser cache, hard refresh. Document this in the runbook so it isn't escalated as a platform incident.
• Silent config no-op. A meta key that isn't in the Vue props array is discarded without warning — a stakeholder requirement can appear "delivered" while doing nothing. Mitigate by cross-checking every key against Card.vue at review time and verifying visually.
• Wrong salutation for the user's timezone. If the greeting is computed from browser time, users in other regions see a salutation that disagrees with session locale. Decide whether that's acceptable or override the greeting via meta with a server-computed value.
• Empty or null name. SSO and provisioned accounts sometimes lack name, producing "Good morning, " or a broken string. Fix in meta ('name' => $user->display_name ?? $user->email), never by patching the Vue file, which composer update will overwrite.
• Post-Nova-upgrade invisibility (highest impact, lowest frequency). A card built against Nova 4 installing cleanly and rendering nothing on Nova 5 is the realistic worst case. Mitigation: branch and visually confirm render before merging any Nova upgrade, and don't trust composer update to warn you.

Ramp-up. Effectively none for the adopting engineer — the install and registration pattern is idiomatic Nova and the card has no domain concepts to learn. Budget the half-day for install plus review, and treat the real ramp-up as organizational: getting the security/provenance review done, agreeing placement and audience gating with the stakeholders who own the admin tooling, and writing the two-line runbook entry for blank-card triage and the fork decision point. If the effort estimate ever exceeds a day and a half total, the correct move is to write the card in-house and skip the dependency entirely.