Easy Api Platform Laravel Package

Getting Started

Run the stack-fit gate before you type composer require. This package is an integration layer for API Platform, which is Symfony-first. If your day job is a Laravel monolith using Route::apiResource, Eloquent API Resources, FormRequest validation and LengthAwarePaginator, this is not a dependency you can adopt — it solves a problem you don't have. Two legitimate entry points remain:

1. You run API Platform already (a Symfony service alongside your Laravel apps, or a Laravel app on an API Platform bridge) and want cross-cutting house conventions on top of it.
2. You are reading it as a reference implementation — pulling the patterns and reimplementing them Laravel-native. Given 0 stars, 0 dependents and read-only split provenance, this is the recommended path.

If you are genuinely on API Platform:

composer require eonx-com/easy-api-platform

With Symfony Flex, EasyApiPlatformBundle should be auto-registered in config/bundles.php; add it manually otherwise. Confirm the runtime matrix first — PHP version, API Platform major, and whether the bridge you use is actually exercised by this package — from the split repo's composer.json constraints, not from the prose description.

Where to look first, in order:

1. composer.json of the split package — the real support matrix is the require/require-dev block, not the README.
2. src/ for the DI extension and the config tree — that inventory is the documentation at this maturity level.
3. The parent monorepo, not the split repo. It carries the tests, issue tracker, changelog and release narrative. The split repo has none of these.
4. Its siblings (easy-error-handler, easy-pagination, easy-test-utils, easy-standard) — this package is glue for the suite, and its conventions only make sense in that context.

First use case: take one representative CRUD resource, enable it, hit the endpoint, and diff the response shape against stock API Platform (status codes, pagination metadata, error body, serializer output). That diff tells you what the package actually contributes versus what the framework already gives you. Timebox this to an afternoon.

Implementation Patterns

Default pattern for a Laravel team: borrow, don't buy. The value here is one team's opinionated answers to problems you keep re-solving. Reimplement them in Laravel-native form under MIT attribution:

Extract the contracts (error envelope shape, pagination metadata keys, filter whitelist rules) and encode them as tests, not as a dependency.

If you actually adopt it inside an API Platform app:

• Wrap everything. Never reference EasyApiPlatform classes from domain code. Introduce your own interfaces/aliases so removal is a provider deletion, not a refactor.
• Confine the diff. All configuration in one bundle config block or service provider; feature-flag per resource.
• Enable one feature at a time. Serialization first, then filtering, then pagination metadata. Run the contract test suite as the gate after each.
• Contract tests on response shape are the single highest-value mitigation — they turn "silent behavioral drift on API Platform bump" into a red build.

Dependency hygiene, day one:

"eonx-com/easy-api-platform": "1.2.3"

Pin the exact tag, not a caret range, and log the corresponding monorepo commit in a dependency decision record. Configure Renovate/Dependabot to require a human lockfile-diff review on any bump — the split repo offers no meaningful semver narrative to automate against.

Prepare the exit ramp up front: vendor a fork into your own VCS namespace under the same package name and point Composer at it via a path/vcs repository before you need to. Improvising that under incident pressure is how teams get stuck.

For Laravel-only shops, the deliverable is a one-pager, not a package. Half a day from a senior engineer: feature inventory, the conventions you're copying, the extension points you'd have used, and the removal procedure. That artefact outlives the dependency.

Gotchas and Tips

• Read-only subtree split. No issue tracker, no PRs, no tags you can reason about. Bugs route to the parent monorepo. If your dependency policy requires an observable support contract, this fails the screen today.
• Zero dependents means zero external scrutiny. You will be the first to hit every edge case, and the first to discover whether a failure is your config or the library's bug. Budget for source-reading; the code is the documentation.
• Silent behavioral drift is the top risk. On an API Platform major bump, decorators may stop composing and response shapes can change without an exception firing. Contract tests on response shape (keys, types, pagination envelope) are the mitigation — write them before you write features.
• Check what it overrides. Companion libraries like this usually encode conventions rather than expose config. Before adopting, verify it doesn't clobber serializer groups, pagination metadata, or filter resolution you depend on. Grep for decorates, compiler passes, and any services.yaml that replaces core API Platform services.
• Security review anything touching the request pipeline — serialization of sensitive fields, filter exposure, auth hooks. Defaults that upstream never revisits are the second-most-likely failure mode.
• Version drift is your problem. No lockstep tag story between split and monorepo means a bump can pull in behavior you never reviewed. Keep a composer.lock review step in CI.
• Don't import it into a Laravel codebase. Pulling a Symfony-framework companion into a Laravel monolith buys you a transitive Symfony dependency tree and a support burden for zero functional gain. Record that decision so it stops resurfacing in dependency reviews.
• Name an internal owner. If it lands on anything revenue-critical, it belongs in the service catalogue with a named maintainer and a documented fork-and-patch runbook — not an incidental dependency in a composer.json.