Nova Rtl Support Laravel Package

Technical Evaluation

Architecture fit. This is a Nova-only add-on, not a general Laravel package. It sits in the admin panel layer: a service provider that publishes/serves a stylesheet (and possibly view overrides) to flip Nova's chrome to RTL for locales like Arabic, Hebrew, Persian, and Urdu. It does nothing for the customer-facing application. Fit is therefore conditional on two things being true at once: Nova is our admin surface, and an RTL locale is a first-class requirement for the people who use that surface. If either is false, the package has no addressable value regardless of its score.

Integration feasibility. Mechanically easy — Composer install, service provider auto-discovery, vendor:publish for assets. The difficulty is temporal, not mechanical: the last release is May 2019, which puts it in the Nova 1.x/2.x era, while current Nova is 4.x/5.x. Nova is closed-source and commercial, so its internal asset pipeline, Blade views, and CSS class contracts are not something we can inspect or pin against upstream. There is no upgrade guarantee and no one to ask.

Technical risk — high. Concretely:

• Orphaned upstream. Archived, 7 stars, 0 dependents. That is not a maturity signal; it means no community validation, no issue corpus, no third party who has hit the failure modes before us. We become the sole maintainers on day one.
• Brittle mechanism. RTL support implemented as CSS overrides is inherently specificity-sensitive. Visual regressions are silent — they do not throw, they do not fail tests, they surface as a broken admin for a subset of users.
• Closed dependency. Any Nova minor release can invalidate the override sheet without warning, and we will not see it coming in a changelog.
• Scoring caution. A 0.98 score against these signals should be read as a ranking artifact, not an endorsement. The adoption decision needs to rest on the code itself.

Key questions.

1. Which Nova versions does the composer.json constraint actually allow, and what is our pinned Nova version?
2. Does direction flip automatically from app()->getLocale(), or is it a manual config flag? Automatic is table stakes.
3. Does it cover Nova core only (resources, forms, lenses, filters, actions, metrics) or does it also handle third-party Nova tools we already run?
4. Is the change CSS-only, or does it override Blade views? View overrides are far more fragile and far more likely to collide with other packages.
5. What is the license, and does it permit forking and internal vendoring?
6. Is Nova's native localization plus a small in-house override sheet actually cheaper than adopting this? Given the apparent size of the delta, this is a live option, not a rhetorical one.

Integration Approach

Stack fit. Laravel + Nova, nothing more. It solves the admin slice of an RTL requirement and should be scoped as such. If RTL is required for the customer-facing app, that is a separate workstream (locale routing, front-end direction handling, logical CSS properties) and this package contributes nothing to it. Framing it as "our RTL solution" is the most likely way this goes wrong politically.

Migration path. Do not consume it as a live dependency. Fork it, vendor the source into our repo, pin the commit, and treat the CSS as first-class internal code with an owner. Given the age and size, the realistic comparison is fork-versus-rewrite: the delta is likely a few hundred lines of override CSS, and rewriting against our exact Nova version may cost less than reconciling a six-year-old sheet. Run that comparison during the spike, before committing to either.

Compatibility. Verify PHP and Laravel constraints, the nova constraint, auto-discovery behaviour, and publish tags. Then check for collision: any other Nova package overriding the same views or injecting competing styles is an immediate conflict candidate. Confirm whether assets are published to public/vendor (deploy-pipeline concern) or served from the package.

Sequencing.

1. Spike on a branch against our exact Nova version. Install, publish, and walk every core Nova screen in an RTL locale: index, detail, create/edit forms, lenses, filters, actions, metrics, settings.
2. Enumerate regressions and classify as core-only vs. third-party-tool breakage. This is the input to fork-vs-rewrite.
3. Decide and own. Fork or rewrite, name a maintainer, document the override contract.
4. Staging rollout with native-speaker QA on the admin, not just a screenshot review.
5. Production, gated behind a config flag so RTL can be disabled per-environment if a regression lands.

Operational Impact

Maintenance. Zero upstream maintenance — the archive status means we absorb 100% of it. Budget explicitly for one maintenance task per Nova major upgrade, and a verification pass on every Nova minor. That recurring cost is the real price of the package, not the install.

Support. None available. No issue triage, no maintainer, no documentation depth, and with 7 stars and 0 dependents there is no community corpus to search. Internal documentation and a named owner are mandatory, not optional.

Scaling. Runtime cost is negligible — static CSS, no query or request-path impact. Technical scaling is a non-issue. Organizational scaling is the actual constraint: every new Nova tool, card, or filter added to the admin becomes a new RTL verification obligation, and that obligation grows with the admin surface, permanently.

Failure modes.

• Silent visual regression after a Nova upgrade — CSS overrides stop matching, layout degrades for RTL users only.
• Partial coverage: core Nova renders correctly, a third-party tool does not, producing a half-mirrored admin that is harder to use than no RTL at all.
• Publish/asset pipeline conflict overwriting public/vendor on deploy.
• Specificity war with another package's style injection.
• Worst case, degraded usability for RTL-locale admins. Critically, this is a soft failure — it does not page anyone, does not 500, and will be discovered by users rather than monitoring. That argues for a smoke check in CI on the admin's rendered direction, not reliance on alerting.

Ramp-up. Low for a competent Laravel developer to install — under a day. Medium-to-high to maintain: debugging specificity against Nova's compiled CSS is a narrow skill, and it must be paired with a native RTL reader for QA. Plan for that pair, not just the developer.