- Is gheb/api-platform-config-converter-bundle a Laravel package?
- No. It is a Symfony bundle that ships a Bundle class and a DI extension and depends on Symfony's kernel plus API Platform's metadata and configuration subsystems. There is no service provider, no config publish tag, and nothing designed for a Laravel service container. If your stack is Laravel-first, this package does not fit and should not be forced into it.
- What does this bundle actually do?
- It converts API Platform resource configuration from one format to another, historically taking YAML, XML, or annotation-based resource definitions and emitting PHP attributes. It behaves like a build-time codemod rather than a runtime library. Nothing in it belongs on the request path.
- Can I install it via Composer in a Laravel application?
- Composer will resolve it, but registering a Symfony bundle inside a Laravel app means fighting its wiring assumptions for no runtime benefit. The realistic approach is to fork the repository, run it in an isolated branch or scratch Symfony app, review the generated diff, and remove the package from composer.json before merging. Treat it as a throwaway toolchain step, not a dependency you keep.
- Which source and target formats does this version support?
- The documented scope is YAML, XML, and annotation-based resource definitions converted toward PHP attributes in the API Platform 3+ era. Because the repository is archived, you should verify the exact supported pairs against the tags and README rather than assuming parity with current API Platform releases. Do not assume round-trip support; conversion is one-way.
- Which API Platform and Symfony versions is it compatible with?
- It was written against the API Platform 2.x to 3.x transition period and there is no evidence of API Platform 4 readiness. Being archived, it will not receive PHP or Symfony version ceiling raises, so expect to be pinned to older majors. Pin your fork to a specific tag and record the upstream commit SHA so the migration stays reproducible.
- Is this package still maintained?
- No. The repository is archived, has roughly 17 stars, zero dependents, and a single maintainer, so there are no security patches or compatibility updates coming. There is also no issue history to mine for known failure modes. Treat it as a frozen one-shot tool, not something you can rely on over time.
- Does the conversion preserve API behavior exactly?
- Not reliably, because the formats are not isomorphic. Nested operation blocks, filter arguments, serialization groups, security expressions, and validation constraints may be expressed differently or silently dropped. Silent omission is the dominant risk: generated code that compiles and boots but changes API behavior. Review the output as a diff and classify every change as faithful, semantically lossy, or dropped.
- How should I test or validate the converted configuration?
- Run the converter against a frozen snapshot of your resource configuration, then review the result as a diff rather than accepting wholesale rewrites. Boot the application and run your API contract and functional tests, comparing generated OpenAPI documentation before and after. Hand-remediate anything classified as lossy or dropped before merging.
- Should this run in CI or production?
- No. It is a developer-branch codemod, not a pipeline component or runtime dependency. Keep the fork pinned in an isolated branch, run it manually against a snapshot, and strip it from composer.json before merge. Archive the fork with a README documenting the run so the migration is reproducible later.
- What are the alternatives to using this bundle?
- The safe alternatives are a manual rewrite of resource definitions or writing your own small codemod targeted at your actual resource inventory. If you are already on PHP attributes, this package offers zero value. There is no maintained, battle-tested equivalent, so budget manual remediation as the majority of the effort either way.