Nova Tailwind Laravel Package

Product Decisions This Supports

• "Extend Nova" vs. "build a separate internal admin app." This package lowers the marginal cost of shipping custom Nova cards, tools, fields, and dashboards for teams already standardized on Tailwind. If the roadmap contains several admin-surface features (KPI cards, ops dashboards, internal tooling), it makes extending Nova the cheaper path. With one admin feature or none, it changes nothing.
• One design system across product UI and the admin surface. The durable product argument: a single utility vocabulary reduces design drift between the customer-facing product and the internal admin shell. That is a lasting consistency benefit, not a point-in-time convenience.
• Build vs. buy for internal tooling. A small, real input into Nova-vs-custom-admin-vs-SaaS-admin comparisons. It nudges toward extending Nova—marginally. It should never be the deciding factor.
• Roadmap sequencing and dependency posture. Archived, last release 2021-11-12, 55 stars, zero dependents, vendor renamed optimistdigital/* → outl1ne/*. Treat it as a freeze-and-vendor input, not an anchor for a multi-quarter tooling strategy. It shapes how you sequence admin work (ship on a pinned fork now; migrate when Nova's native asset pipeline covers the need), not what you build.

When to Consider This Package

Consider it only when all of the following hold:

• You are on a legacy Nova major (Nova 3 era) whose asset pipeline does not natively accommodate Tailwind in custom tools.
• You have—or have explicitly planned—custom Nova components that must match an existing Tailwind-based design system.
• You accept vendoring or forking an archived MIT package: exact version pinned, lockfile committed, a named internal owner, and a documented exit plan.

Look elsewhere—or drop the dependency—when:

• You are on Nova 4+ or a modern Vite-based build, where native Tailwind support and Nova's nova.mix.js tooling make this loader redundant. The equivalent is roughly 20–40 lines of tailwind.config.js you own outright.
• You require an actively maintained dependency with a security-response channel. Archived plus a 2021 release is a maintenance liability, not a foundation.
• Your team has no Tailwind design system to align to—it adds toolchain surface for zero product benefit.
• You are evaluating Nova itself. This is a downstream styling detail and must not influence that buy decision.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed developer utility that styles the internal admin panel. It is not customer-facing, carries no licensing cost, and has no runtime footprint—no performance, data, or availability implications. The material point is risk and ownership, not capability: the package is archived and unmaintained (last release 2021, zero downstream dependents, vendor renamed). Recommendation: do not build roadmap commitments on it. If a current team genuinely needs it for legacy-Nova work, fork and pin it under a named owner and schedule retirement at the next admin-panel upgrade. The replacement is a handful of config lines we can own and test internally—cheap, low-drama, and one fewer unmaintained dependency in our supply chain.

To engineering: It is a Tailwind loader/preset for Nova that keeps custom Nova tools visually consistent with app styling on legacy Nova. Adoption cost is one dev dependency plus a config extension; removal cost is likewise trivial. Treat it as a vendored fork, not a living upstream: pin the version, commit the lockfile, extract the Tailwind preset into our repo so the config survives without the Composer wrapper, and add a visual-regression check on the admin build so silent CSS purging or preflight collisions are caught in CI rather than by an operator. Document why it exists and file a ticket to revisit once Nova's first-party asset tooling covers the use case.