Statamic Markdown Table Laravel Package

Product Decisions This Supports

• Markdown authoring parity. Statamic's Markdown Fieldtype renders through CommonMark, where GFM-style tables are an opt-in extension. This package targets that gap: letting editors write pipe-and-dash tables in Markdown and have them render as real <table> output instead of escaped text. That makes it a decision input for "can our writers stay in Markdown, or do we need a structured fieldtype?"
• Build vs. buy for a narrow content need. The alternative is in-house: a custom Markdown extension plus sanitization, CSS, and responsive-scroll handling — small but perpetual surface area. This is a cheap off-the-shelf candidate to benchmark against a 1–2 day internal spike.
• Fieldtype strategy / editorial tooling roadmap. Directly relevant to whether your content model standardizes on Markdown or Bard for body copy. If Markdown tables are a recurring author request, this package is the low-friction answer; if tables need column resizing, header config, or per-cell styling, it argues for the structured/Bard path instead.
• Upgrade and dependency-risk planning. A 1.0.0-beta is a decision about tolerable risk, not a feature decision. It supports "pin and pilot" over "adopt as standard," and it flags a Statamic-version compatibility question you should answer before it enters a shared codebase.
• Documentation/migration content decisions. If adopted, table syntax becomes part of your editorial style guide and any content migration/import tooling — worth knowing before writers produce tables at scale.

When to Consider This Package

Consider it when all of these hold:

• You run Statamic and the affected content is authored in a Markdown Fieldtype (or Markdown-rendered Bard sets), not a table-capable structured field.
• Writers are already hand-writing or pasting Markdown tables and complaining about broken output — a concrete, observed need, not a speculative one.
• Tables are simple: header row plus data rows, no merged cells, no per-cell formatting beyond inline Markdown.
• You can tolerate beta: pin the exact version, pilot on one collection or a staging site, and accept that the config surface may shift before 1.0.0.
• The maintenance surface is acceptable — a small addon with a short release history means you are effectively the fallback maintainer.

Look elsewhere (or build in-house) when:

• You need rich table editing — add/remove columns in the UI, alignment controls, responsive behavior, CSV paste. Use a structured table fieldtype or Bard with a table set instead; a Markdown text syntax will not satisfy those editors.
• You need production SLAs, security review, or a support contract. A beta with a single release note gives you no signal on maintainer responsiveness, test coverage, or disclosure history.
• Your Markdown pipeline is customized already (custom CommonMark extensions, sanitization policy, cached/static rendering). Verify the package composes with your extension list rather than assuming it does; a competing league/commonmark table extension may be the more direct lever.
• Your Statamic version is outside the package's tested range — unverified compatibility is a hard stop for anything customer-facing.
• Content portability matters: confirm tables degrade gracefully if the addon is later removed, rather than leaving raw pipes in rendered output.

Validation before adopting (the release note is one line — treat the rest as unknown): supported Statamic/PHP versions, whether it registers a CommonMark extension vs. a fieldtype vs. a parser, output sanitization behavior, whether Bard is covered, test suite presence, license, and maintainer history.

How to Pitch It (Stakeholders)

For executives (one paragraph): A small, low-cost addon that lets our editors put tables into Markdown content without engineering involvement. The business case is cycle time on content publishing, not a new capability — editors currently either avoid tables or file a ticket. Cost is near zero; the risk is that it's a 1.0.0-beta from an addon with minimal public history, so we're recommending a timeboxed pilot on one section rather than an org-wide standard. Decision requested: approve a ~1 day pilot, with adoption contingent on the compatibility and output-quality checks below. If the pilot fails, the fallback is a structured table field, which we'd need anyway for complex tables.

For engineering (what we're actually asking): Install pinned to 1.0.0-beta, verify Statamic/PHP compatibility, confirm the implementation mechanism (CommonMark extension vs. fieldtype), and confirm rendered HTML is sanitized and escapes as expected in both Markdown and Bard contexts. Check whether it conflicts with our existing league/commonmark extension configuration, and confirm content falls back readably if the addon is removed. Deliverable: a short written verdict — adopt, adopt-with-caveats, or build a ~50-line custom extension instead.

Framing to avoid: don't position this as "Markdown gets tables." Position it as "a cheap experiment to remove an editorial ticket queue, with a known exit ramp." That keeps the beta status an explicit, accepted trade-off rather than a surprise at launch.