Nova Markdown Laravel Package

Product Decisions This Supports

• Admin authoring investment. Frames a bounded upgrade to the internal editing experience inside Laravel Nova — internal docs, blog drafts, FAQs, knowledge-base entries — swapping a raw textarea for a split-view Markdown editor with live preview. This is a productivity enhancement, not a differentiator, and should be scoped and budgeted as such.
• Build vs. buy (the real call). The honest comparison is not "this package vs. nothing," but "this package vs. a thin in-house Nova field wrapping a maintained editor (EasyMDE or Toast UI)" — roughly 1–2 engineer-days. At 10 stars, 0 dependents, and a last release in September 2023, building in-house is a legitimate contender, not a fallback. Default to build unless a half-day audit clearly favors the package.
• Content-format strategy. Because content persists as plain Markdown in an existing TEXT/LONGTEXT column, adoption reinforces a deliberate vendor-neutral storage decision. Encode "never introduce a proprietary JSON or block schema" as a hard constraint so a future contributor cannot create lock-in. Rendering remains a separate, app-owned, server-side concern.
• Editor UX direction (Markdown vs. WYSIWYG). Forces an explicit decision about who the author is. Technical writers get a split-pane Markdown surface; marketing, support, or other non-technical editors almost certainly need WYSIWYG or a dedicated CMS. This is a staffing and product decision, not just a tooling one — no amount of configuration fixes the wrong author/editor pairing.
• Roadmap prioritization. Classify as an internal productivity enhancement and time-box it. Do not let any roadmap dependency form on a single-maintainer, 2023-era package. The correct planning artifact is a pilot ticket, not a platform initiative.
• Media/upload scoping. Decide up front whether image or file uploads are in scope. If the field exposes them, they can bypass your storage abstraction, ACLs, and lifecycle rules — the easy default answer is "no," keeping the media pipeline where it belongs.
• Risk-acceptance decision. At 10 stars, 0 dependents, one maintainer, and a stale release, adoption is a decision to own the code. That is fundable only with a named owner, pinned versions, a documented revert-to-textarea path, and a recurring Nova-upgrade allowance that lands on the same calendar as Nova upgrades.

When to Consider This Package

Consider it when:

• You already run Laravel Nova (paid, separately versioned) and need Markdown authoring for a small set of internal, technical users.
• Requirements are simple: edit, toolbar, live preview, plain-text storage — no collaboration, approvals, media workflows, or enterprise support.
• You can accept MIT with no SLA and are prepared to audit, vendor, or fork the code.
• A 0.5-day audit confirms (a) the package's composer.json constraint on laravel/nova matches your pinned major today and across your upgrade roadmap, and (b) the live-preview HTML is sanitized, or app-layer sanitization is enforceable on your read path.
• The value is speed of implementation and improved admin UX — realistically under half a day for a Nova-fluent developer.

Look elsewhere when:

• You are not on Laravel + Nova (Filament, Blade, Livewire, Inertia, standalone admin panels: zero fit).
• The requirement is Markdown rendering for end users — a separate server-side concern this package does not address.
• Content is public-facing, regulated, security-sensitive, or business-critical, or you need accessibility guarantees.
• You need active maintenance, vendor support, security response, media workflows, or multi-user collaboration.
• Non-technical editors are the primary users (WYSIWYG or a CMS fits better).
• You cannot tolerate a 2023-era constraint set against current Nova/Laravel/PHP without staging validation — including the asset-publish step, where custom fields most often break silently.
• The in-house alternative really is 1–2 engineer-days. At this package's adoption level, that is a genuine competitor rather than a fallback.

How to Pitch It (Stakeholders)

Executive summary. A small MIT-licensed field that adds a Markdown editor with live preview to Laravel Nova admin screens. It is a low-cost, low-strategic-value productivity add-on — not a platform bet. Approve only a time-boxed pilot (audit + spike + one sprint) on a non-critical internal workflow, with a named owner and a pre-approved rollback to the default textarea. The downside is bounded: content is stored as plain Markdown, so there is no data migration and no lock-in. If the pilot does not end with a rendered, sanitized page from a real Nova resource, the fallback is a thin in-house field — days, not quarters.

Engineering summary. It is a presentation-layer Nova field: a PHP field class plus pre-compiled Vue assets that store raw Markdown and render a client-side preview. Treat the README as a starting point and src/ as the spec — verify the namespace, the fluent option methods, and whether assets ship pre-built or require a Node build. Two implementation rules carry the risk: never render the preview's HTML in production (own the read path through Str::markdown() or league/commonmark with html_input => 'strip' and allow_unsafe_links => false, behind a single renderer service), and never mount the editor on index views (use a cheap read-only column instead). Pin Nova and the field to exact-ish constraints, run nova:publish in the deploy pipeline rather than only locally, and put a config-gated swap back to Textarea::make() in the runbook before the pilot starts. Assume we are the maintainer: budget review time on every Nova major upgrade.

One-line framing for the steering conversation. "A weekend-sized admin UX improvement with a documented exit, gated behind a half-day audit — approve the pilot, not the dependency."