Filter Card Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin Nova extension: one Card subclass, a service provider that registers the card and its published assets, and a Vue component that reads/writes Nova's route query string. There is no backend service, no database migration, no queue or event surface. Architectural surface area is essentially zero.
• Fit is limited to Laravel Nova 1.x/2.x (Vue 2, PHP 7.x, Laravel Mix). On Nova 4/5 (Vue 3, Vite) assume it will not resolve, compile, or mount until proven in a spike.
• Its real architectural value is as a reference pattern: filters rendered as a dashboard card, coupled to metrics through ?param= query state so Back/Forward and bookmarkable dashboards keep working. That pattern is reusable in-house even if the package is not.
• It is a display/control card, not a filter-management system. No persistence, no per-user saved views, no sharing or permissions — those would be separate scoped features.

Integration feasibility

• Two hard walls, in order: (1) Composer resolution against the laravel/nova and php constraints, and (2) asset compilation (Laravel Mix bundle vs. a modern Vite build). Both are discoverable in a half-day by reading composer.json and the Vue source.
• --ignore-platform-reqs is not a viable path; it defers the failure to every fresh clone, every new hire, and CI.
• The sustainable path, if the UX is wanted, is fork-and-vendor into nova-components/ via a Composer path repository (plus a replace entry where needed) — or simply reimplement the pattern in-house. Estimated in-house effort: an afternoon to a few days, not a sprint.
• Blocking legal check: the repo appears to have no LICENSE file, which is all-rights-reserved by default and blocks internal redistribution/forking until resolved. Verify in discovery, not after vendoring.

Technical risk

• Unmaintained: last release 2019-02-10, 25 stars, 0 dependents, no tests, no CI, no evident maintainer. Bus factor is effectively zero.
• Private-API coupling: Nova cards bind to Nova's internal frontend API, so every Nova major upgrade is a migration you own. Expected failure mode is silent — the card simply stops rendering, with no PHP error and no exception.
• Dependency graph untrusted: 2019-era package.json pins will almost certainly trip npm audit with no upstream fix. Any fork inherits a JS toolchain bump.
• State desync and collisions: if filter state is cached in component data instead of re-read from $route.query, the UI desyncs on Back/Forward. Two cards or a card plus a resource filter both writing ?status= will fight — namespace params (?fc_region=) if coexisting.
• Scope risk: acceptable only on internal admin surfaces. Not customer-facing.

Key questions

• What Nova version are we actually on, and does the composer.json constraint resolve without flags? (Answer this first; it determines ten-minute install vs. fork vs. skip.)
• Is the repo's license permissive enough to fork and redistribute internally?
• Does the filter-summary UX solve a real ops/support workflow problem, or is native Nova filtering already sufficient?
• Do we want to own a card through every future Nova upgrade, or is the value one-time (read the pattern, build once)?
• Which metrics will read the same query params, and what are the canonical param names to avoid collisions?

Integration Approach

Stack fit

• Fits only a Nova 1.x/2.x + Vue 2 + Laravel Mix stack. On a modern Nova (Vite, Vue 3), treat it as a code sample, not a component — you would rewrite the JS entrypoint and card registration anyway, at which point you have built it yourself.
• The coupling contract is the URL query string, which is also Nova's native filter transport. That is the right seam: the card owns filter state, metrics read it, and no props or shared store are required.

Migration path

• Recommended sequence: spike → read → decide → build, not install.
  1. Half-day spike in a sandbox: read composer.json, the Card subclass, the provider, and the Vue component (fifteen minutes of reading covers the whole surface). Run npm audit.
  2. Confirm the license.
  3. If the UX is wanted, build in-house against the current Nova version: Card subclass with component(), a Vue SFC registered via Nova.booting, a provider that publishes the compiled bundle, and query-string read/write.
• If a Nova 2.x sandbox install is genuinely required for evaluation: composer require, publish assets (vendor:publish --tag=filter-card-assets or nova:publish), rebuild with the package Mix config, register in NovaServiceProvider::cards(), then load the dashboard and confirm the card mounts with no console errors before wiring real filter definitions.
• Do not leave the Packagist dependency in place long-term. If you proceed, vendor it into nova-components/filter-card/ with a path repository and document why in the repo, so the next engineer doesn't delete it and break the build.

Compatibility

• Verify the PHP card component() name matches the name registered in Nova.booting; verify the config/meta payload reaches the component via the card prop; verify the router emit and that metrics read identical param names.
• Add a one-line smoke check to the Nova upgrade runbook: load the dashboard, confirm the card renders, confirm changing a filter updates a metric. This is the cheapest guard against the silent-vanish failure mode.
• Never patch inside vendor/. Publish assets and edit the published copy; move to nova-components/ at the first sign of a second change.

Sequencing

• Wave 1 (discovery, ~half day): version check, license check, code read, npm audit. Deliverable: go/no-go on "build this UX."
• Wave 2 (decision): if go, scope a small UI ticket for in-house implementation; do not add to the build/buy matrix as a live candidate.
• Wave 3 (build): reimplement against the current Nova version with namespaced query params and a paired ValueMetric/PartitionMetric reading the same params.
• Wave 4 (optional, later): per-user persistence via a user_settings-style table keyed on user_id + dashboard, hydrated on boot — implemented in your card, not by patching the package.

Operational Impact

Maintenance

• As a dependency: effectively unmaintainable. No upstream releases since Feb 2019, no maintainer, no CI, no tests. Any fix is a local fork, and the fork's JS toolchain will need bumping immediately.
• As a vendored component: maintenance is a known, bounded internal cost — one small card to re-verify at each Nova major. That is the explicit ownership trade the vendor-and-own policy buys.
• As a reference only: zero ongoing maintenance. Often the correct outcome.

Support

• No support owner, no CVE-response path, no upstream issue triage. This fails most procurement/security dependency reviews outright, which is a valid reason to exclude it from composer.json regardless of technical feasibility.
• If vendored, the internal team becomes the support owner by definition. Budget for that explicitly rather than discovering it during an incident.

Scaling

• Load profile is negligible: it is a client-side card reading route state. No additional queries, no server-side processing, no scaling concern.
• The scaling constraint is organizational, not technical: every additional third-party Nova card is another private-API binding that must be re-validated on each Nova major. Accumulating them is the pattern to avoid — this package is the concrete case study for that policy.

Failure modes

• Silent non-render after a Nova upgrade — no error, just a gap users quietly work around. Mitigate with the dashboard smoke check in the upgrade runbook.
• Stale published bundle shadowing source — published assets in public/vendor/... are served as-is. After any edit: rebuild, re-publish, view:clear, hard-refresh; check the network tab for a 404 on the card's JS before debugging Vue.
• Query-param collisions — two cards or a card plus a resource filter writing the same key. Namespace params.
• UI/route desync — filter values cached in component data instead of read from $route.query; breaks Back/Forward and pre-applied filter links.
• Composer breakage on clean checkout — the downstream cost of any --ignore-platform-reqs workaround.

Ramp-up

• Comprehension cost is low: a single PHP Card subclass, a service provider, and a Vue component. Fifteen minutes of reading gives the whole surface area; a day or two of building gives a first-party replacement.
• The transferable knowledge — how Nova-era filters read and write route state, and how to couple a control card to metrics through the query string — is the durable asset here, and it applies directly to any custom filter surface the team builds next, including saved views.
• Recommended posture: allocate a code read, not an onboarding. Keep it out of the dependency graph, put the pattern in-house if the admin UX is worth a small ticket, and record the outcome in the platform policy as the worked example for "vendor and own Nova cards."