Nova Markdown Laravel Package

Technical Evaluation

Architecture fit

This is a single-purpose Nova field package: a PHP field class extending the Nova Field contract, a Vue component registered as a custom field, and a bundled JS/CSS asset pair published into Nova's admin bundle. It is a self-contained extension at the edge of the application, which is architecturally favourable for a TPM's purposes:

• No domain coupling. Markdown content is persisted as plain text in a normal text/mediumText column. There is no proprietary serialization, no side tables, and no write path outside Eloquent. The field is a UI affordance over a string, which means it is fully replaceable without a data migration — the single strongest argument in its favour.
• Rendering is out of scope. The package handles authoring only. HTML rendering, sanitization, caching, and front-end presentation remain the application's responsibility. That keeps the dependency surface small but means the package solves roughly 40% of the "markdown feature" problem — the editing experience, not the published output.
• Blast radius is confined to the Nova admin panel. A failure degrades content authoring; it does not touch public request handling, queues, or the API tier. This materially lowers the cost of getting it wrong.

Integration feasibility

Feasible for a greenfield or Nova 3-and-below installation, with verification gates:

1. Version pin check. Confirm the composer.json constraints accept the target laravel/nova version. A package archived at this adoption level almost certainly caps at Nova 3.x, and Nova 4+ is the current line.
2. Asset delivery model. Determine whether a prebuilt dist/ is committed. If yes, integration can succeed without touching the front-end toolchain even on an older Nova. If it requires a local npm run prod against Nova's Mix/Vite setup, treat Nova 4+ as a hard incompatibility — Nova 4 migrated the field compilation toolchain and archived field packages reliably break there.
3. PHP/Laravel constraint drift. Old field packages commonly pin illuminate/support to versions that block Laravel 10/11 upgrades. This is the most likely cause of a blocked platform upgrade, and it is a silent blocker until the day you try to move Laravel.

Technical risk

Key questions

• Which Nova version is in production, and is a Nova major upgrade planned within 12 months? If yes, this package is a liability, not an asset.
• Is raw-Markdown authoring an actual requirement, or would a plain Textarea with a preview tab satisfy editors? The cheaper answer is often "textarea plus server-side render."
• Who owns sanitization and the render contract, and has that been specified before any non-technical editor touches the field?
• Is there an existing internal fork or a preferred fork-and-vendor pattern in the org?
• Does the editorial workflow need WYSIWYG, or is Markdown literacy an acceptable precondition for the authoring group?

Verdict: conditionally viable as a vendored, owned component for a Nova ≤3 estate; not viable as a straight Composer dependency for a Nova 4+ or upgrade-active estate. The 0.656 score and 0.53 opportunity score are consistent with "works today, decays predictably."

Integration Approach

Stack fit

Laravel + Nova, plain-text storage, server-side rendering via league/commonmark (Str::markdown() on Laravel 9+) with HTML sanitization on the render path. The field slots into a resource's fields() method exactly like a core Textarea. Fit is clean provided the three feasibility gates in the previous section pass.

Migration path

The migration is almost entirely additive and reversible:

1. Ensure the target column exists as text or mediumText and is nullable during rollout.
2. Register the field on a single resource behind a feature flag or branch deploy.
3. Swap existing Text/Textarea fields to the markdown field per resource, one at a time.
4. No data backfill is required — existing plain-text content is already valid Markdown-compatible input, and existing Markdown is already valid plain text. This is the key property that makes the change low-risk.
5. Rollback is a one-line revert to Textarea. Content is untouched. Plan for this and it becomes a near-zero-cost experiment.

Compatibility

Build an explicit compatibility matrix before committing: Nova version × PHP version × Laravel version × asset toolchain. Two outcomes:

• Compatible path: prebuilt assets present, constraints accept the current Nova line → install, pin exactly (no caret ranges on an archived package), vendor the source into the repo or a private registry, and proceed.
• Incompatible path: Nova 4+ or a required upgrade on the horizon → do not install. Choose between (a) a two-week fork to rebuild the field against Nova's current toolchain, or (b) dropping the field and shipping a small in-house Vue component or a textarea-plus-preview UI. Option (b) is usually cheaper than it looks; the editor is the commodity part.

Sequencing

1. Spike (1–2 days): install in a scratch branch, confirm assets load, confirm editor renders and saves, confirm Composer does not downgrade Laravel.
2. Decision gate: fork-and-own vs. replace-with-in-house vs. defer. Publish the decision and the owner.
3. Render contract (before any editor onboarding): define sanitization policy, define where Markdown is converted (on write with a cached HTML column, or on read), and define the allowed HTML subset. This is the security control point and it must precede rollout.
4. Pilot: one low-traffic resource, one or two editors, two weeks.
5. Rollout: resource by resource.
6. Register the maintenance obligation as a recurring backlog item with an explicit review date, since no upstream will prompt you.

Operational Impact

Maintenance

Archived status means the maintenance burden transfers to you on day one, whether or not you acknowledge it. Budget realistically: 2–5 days per quarter for dependency and asset upkeep, and 1–2 weeks per Nova major release to rebuild the field against the new toolchain. If the organisation cannot commit that, the honest answer is to not adopt the package. A vendored fork with CI that builds assets against the current Nova version and runs a smoke test on field registration converts this from an unknown liability into a bounded, estimable cost.

Support

There is no upstream support channel and effectively no community to draw on at 36 stars. Internal ownership is mandatory: a named engineer who can debug the Vue component and the asset registration. Documentation should be written at adoption time, not at first incident — the field's behaviour and the render/sanitization contract need to be discoverable by someone who did not integrate it.

Scaling

Negligible at any realistic scale. The added cost is a client-side editor bundle in the Nova admin JS payload (a few hundred KB, served to a small population of internal users) and Markdown-to-HTML conversion on the render path. The latter is CPU-cheap but should be cached — convert on write into a persisted HTML column, or cache the rendered output — because it otherwise runs per page view and, more importantly, per sanitization pass. Do not put a sanitizer on an uncached hot read path.

Failure modes

• Silent asset breakage after a Nova upgrade: the field renders blank or the admin build fails. Detection is manual unless you have a post-deploy smoke test on the resource form. Add one.
• Composer resolution conflict: the package's Laravel/Nova constraints block a platform upgrade. Surfaces late and expensively; the spike in step 1 is the control.
• XSS: a paste of raw HTML into the editor flows through preview or published output unsanitized. This is the highest-severity failure and the one most likely to be introduced by the integration rather than the package itself.
• Silent content degradation: editors paste rich text from Word/Docs and lose formatting, or produce Markdown that renders unexpectedly. Mitigate with a preview pane, a syntax cheat sheet, and a short style guide.
• Divergence between preview and published output: the editor's preview renderer and your server-side renderer differ. Users will trust the preview; specify that the server is authoritative and keep renderers aligned.

Ramp-up

Developer ramp-up is low — the Nova field API is conventional and the integration is a handful of lines. Content-editor ramp-up is moderate and is the real cost: Markdown is a notation, not a UI, and non-technical authors will need a cheat sheet, a preview they trust, and a support path. Factor a short training artifact into the rollout, and reconsider the requirement if the authoring population is large and non-technical — that is precisely the case where an in-house WYSIWYG or a plain textarea with preview beats a 36-star archived field.