Metayaml Laravel Package

Product Decisions This Supports

• Feature shipping: A YAML-in, YAML-schema-out validator for config-driven features: CI templates, import manifests, tenant settings, workflow/pipeline definitions, i18n files, fixture data, and "bring your own config" surfaces. It replaces hand-rolled validation code with a declarative schema, which is usually one of the first places teams build custom code.
• Roadmap: Supports a "config-as-code" or "third-party configuration" roadmap, where solutions engineers, ops, or partners author YAML and the product must reject invalid input before it reaches core logic.
• Build vs buy: Lean buy/borrow for early validation work. A build is only justified when the schema surface is trivial or when the schema format must be shared outside PHP. Metayaml is a reasonable first implementation behind an interface; the interface is the real product decision, not the library choice.
• Use cases: Internal validation of user- or ops-supplied YAML; validating test fixtures and seed data; enforcing required fields, nested types, enums, and partial schema reuse without a bespoke validator. Not the right layer for customer-facing API contracts.
• Risk posture: Treat as a deliberate, contained dependency with an exit plan. Low stars and low activity mean it is a short-to-medium-term tool, not a long-term platform bet.

When to Consider This Package

Consider adopting when:

• Your inputs are genuinely YAML and will stay YAML. The schema can live next to the data and be owned by non-PHP authors.
• You need nested structure validation, required/optional keys, enums, partial schemas, and imports, and you want that in days rather than building a validator.
• The team is small and you value a single small dependency over a heavier JSON Schema engine.
• Validation is an internal, bounded concern (configs, fixtures, manifests) where library maintenance risk is acceptable.
• You can wrap it behind a ValidatorInterface so the schema engine can be swapped later.

Look elsewhere when:

• Inputs can be JSON. Use JSON Schema (opis/json-schema, justinrainbow/json-schema) for better tooling, editor support, and an actual specification.
• You need an actively maintained dependency. With ~103 stars and weak activity signals, expect to vendor, fork, or replace it within a release or two.
• The schema must be consumed by other services or languages. Metayaml's schema DSL is PHP-only; a non-PHP service cannot enforce it, which splits your source of truth.
• You need generated docs, IDE autocompletion, or OpenAPI/AsyncAPI alignment. Neither this package nor its format provides that.
• Performance is a hard constraint (streaming, very large files, high-volume request validation). Symfony YAML parsing plus schema traversal is not a hot-path tool.
• A plain Laravel Validator plus Yaml::parse() covers your needs. Simpler, already in the stack, no extra dependency.

How to Pitch It (Stakeholders)

For executives: "We're considering a small MIT-licensed PHP library, metayaml, that lets us describe what a YAML configuration file should look like once and then automatically reject bad configs. It shortens delivery for our config-driven features by avoiding a custom validator, and it reduces support tickets caused by malformed configuration. It's low-commitment: we'll wrap it behind our own interface so we can replace it with JSON Schema or in-house code if we outgrow it. The main caveat is maintenance — the project isn't actively developed — so we treat it as a contained, replaceable tool, not a platform dependency. Estimated saving is [X engineer-days] against a modest ongoing watch item."

For engineering: "It's a schema validator for YAML, where the schema itself is YAML. We get nested types, enums, required fields, partials, and imports without writing a validator. Use it for internal configs, fixtures, import manifests, and pipeline definitions — not for public contracts. Put it behind a ValidatorInterface, pin the version, and add our own tests for semantic rules the library can't express. Watch the Symfony YAML dependency and the project's activity; assume we may fork or replace it. Do not expose the schema format to customers."