Front Matter Laravel Package

Product Decisions This Supports

• Build vs. buy for content ingestion: If the roadmap includes Markdown-based articles, docs, changelogs, or imported content with YAML metadata, this package removes a small but real piece of undifferentiated plumbing: splitting --- metadata from body content. That lets the team spend effort on editorial workflow, permissions, search, and rendering instead of parser edge cases.
• CMS and migration scope: Useful when importing existing Markdown corpora from static site generators, Git-based docs, or legacy CMS exports. A PM can scope an importer as “parse front matter + map fields + persist body” rather than commissioning a custom format parser.
• MVP and time-to-market: For a Laravel app that needs a lightweight “content file → structured record” pipeline, this supports a smaller MVP: an Artisan import command, a seeder, or an admin upload flow can produce title, slug, date, tags, and body without a full CMS purchase.
• Architecture boundary: Encourages keeping document parsing behind a small adapter/service rather than scattering delimiter logic across controllers and jobs. That is a product-relevant decision because it reduces future migration cost if the content model or package changes.
• Feature prioritization: If front matter parsing is not a differentiator, adopting a small MIT-licensed library is usually preferable to building and maintaining one. This frees engineering capacity for customer-visible features.

When to Consider This Package

Consider it when:

• The product needs to ingest or store Markdown-like documents with YAML metadata enclosed in --- delimiters.
• The metadata model is simple: title, slug, date, tags, draft status, description, and similar scalar/list fields.
• The application is Laravel/PHP but the parsing concern is framework-agnostic; the package can sit behind a service class or job.
• The team is comfortable owning a thin integration layer, pinning the Composer version, and adding its own tests around expected document formats.
• License compatibility (MIT) and a dependency-light footprint matter more than a large ecosystem or commercial support.
• The use case is internal tooling, a content importer, a docs pipeline, or a low-to-moderate-volume editorial feature.

Look elsewhere or build in-house when:

• You need full Markdown rendering, HTML sanitization, syntax highlighting, or a complete content platform. This package only separates metadata from body; it is not a renderer or CMS.
• You need advanced YAML features, strict schema validation, custom tags, or security hardening around untrusted YAML. Pair it with a dedicated YAML parser/validator or choose a more comprehensive content library.
• The content pipeline is high-volume, latency-sensitive, or business-critical. A 40-star package with limited community visibility should be treated as a small utility, not a strategic dependency; verify maintenance, release cadence, PHP version support, and issue responsiveness.
• You already have a framework component or platform feature that handles front matter. Adding another dependency may create duplication.
• You require vendor support, SLAs, long-term security guarantees, or formal auditability. In that case, evaluate maintained alternatives or a small internal parser with explicit ownership.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility that can shorten delivery of content-import and Markdown-editorial features. It is low-cost and easy to isolate, so the main risk is not financial but dependency ownership. Recommendation: approve a time-boxed spike, wrap it behind our own service, and avoid making it a platform-wide standard until usage proves out.

For engineering: The package does one job: extract YAML front matter and return metadata plus body. It is framework-agnostic and Composer-ready, so it fits a Laravel importer, Artisan command, or content service without coupling to our domain model. We should pin the version, add contract tests for documents with and without front matter, and keep the integration behind an interface so we can swap it if maintenance or edge-case coverage becomes a concern. Treat it as a convenience dependency, not a core platform bet.