Configuration Converter Bundle Laravel Package

Product Decisions This Supports

• API Platform configuration migration (YAML/XML → PHP attributes): The single strongest use case. If the roadmap includes upgrading to API Platform 3+ where PHP attributes are the documented default, this bundle converts existing resource definitions mechanically instead of by hand — a direct input to "how many sprints does the upgrade cost?" estimates.
• Build vs. buy vs. script: For a conversion that runs once, the real decision is "adopt a bundle" vs. "write a 200-line throwaway script." This package is the middle option: cheaper than building, but archived and unmaintained, so it must be treated as scaffolding, not a dependency you inherit.
• Scope sizing for tech-debt work: Running a conversion gives you an accurate inventory of every API resource, operation, and serialization group declared in config — useful data for prioritizing which resources to refactor first.
• DX / onboarding decisions: Format standardization (one canonical config style, ideally attributes colocated with the entity) reduces the number of places a new engineer must look. This supports a "reduce configuration surface area" initiative with a concrete tool behind it.
• Framework fit check (flag for the record): Despite being filed as a Laravel/PHP package, this is a Symfony bundle. It is only relevant if API Platform is already in the stack — API Platform is a Symfony-first framework, so a Laravel-centric roadmap should treat this as out of scope rather than a candidate dependency.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony-based and already uses API Platform with config in YAML or XML.
• The need is a one-time, human-reviewed migration, not a recurring or bidirectional sync.
• The API surface is modest (roughly tens of resources, not hundreds) so that manual review of the generated output is tractable.
• You can vendor or fork the code: archived status means no security patches, no compatibility fixes for newer API Platform releases, and no issue triage. Pin it, copy it into tools/, and delete it after the migration.
• The output is treated as a draft: generated config must be diffed and reviewed, because custom extensions, metadata, and edge-case attributes are exactly where converters lose fidelity.

Look elsewhere (or hand-roll) when:

• You need ongoing conversion, round-tripping, or conversion in CI — an archived repo with 17 stars and zero dependents is not a maintenance-grade dependency.
• You are on API Platform 4.x or an unlisted version; compatibility is unverified and there is no upstream to fix it.
• The API surface is large or heavily customized, making review cost exceed manual migration cost.
• Your organization requires a supported dependency with an SLA, CVE response, or named maintainer — archived fails all three.
• The stack is Laravel: there is no native API Platform integration, so the premise doesn't apply.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed developer tool that automates a tedious config-format migration during an API Platform upgrade. It carries no runtime risk — it is used offline, produces reviewable output, and is removed after the migration. The trade-off is that it is archived and unmaintained (17 stars, no dependents), so we use it as a head start on a one-off task, not as a library we depend on. Expected benefit is engineering hours saved on mechanical conversion; the cost is a review pass and the discipline to delete it afterward.

To engineering: Treat it as a migration accelerator, not a dependency. Vendor it, run it against a branch, diff every generated file, and expect to hand-fix custom extensions and non-standard metadata. Verify compatibility against your exact API Platform version before committing to the approach — the repo is archived, so any incompatibility is ours to fix or abandon. If the conversion is small, a short script may be the better call; do a timeboxed spike first and keep the escape hatch open.