Api Platform Traits Laravel Package

Product Decisions This Supports

• API-first backlog scoping. This package exists to remove boilerplate from API Platform resources — identifiers, createdAt/updatedAt, and soft-delete columns. If your roadmap includes a Symfony/API Platform service where every entity repeats the same six fields and lifecycle hooks, this is the "don't build it yourself" option for that narrow slice.
• Build vs. buy for entity plumbing. Provides six traits covering the standard CRUD-plus-audit shape: OrmIdentificatorTrait, OrmTimestampableTrait, OrmSoftDeletableTrait, and ODM equivalents. A PM decision here is really "do we spend sprint capacity on trait conventions, or adopt someone else's?"
• Audit/soft-delete as a compliance answer. Timestampable plus soft-deletable traits map directly to "we need to know when records changed" and "we must not hard-delete user data" requirements. Those are product requirements, not just code style — this package is one way to satisfy them cheaply.
• Migration/tech-debt planning. If you're on API Platform and your entities hand-roll these fields, this is a candidate consolidation task. Note the framing: despite the "Laravel/PHP" label in the brief, this is a Symfony + API Platform + Doctrine package (it also wires into stof/doctrine-extensions-bundle and Gedmo annotations). It is not Laravel. Any decision to adopt it is a Symfony-stack decision.
• Risk register input. One star, zero dependents, last release April 2020. As a PM input, this is not a dependency to standardize on — it's a pattern to copy.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony + API Platform + Doctrine (ORM and/or ODM), not Laravel.
• You are already using, or willing to adopt, stof/doctrine-extensions-bundle and Gedmo annotations — the package does not deliver soft-delete behavior on its own; it assumes you've configured the extension.
• The scope is genuinely internal and small: a handful of entities needing id/timestamps/soft-delete, with no expectation of upstream maintenance.
• You treat it as reference implementation rather than dependency — read the traits and vendor the pattern into your own src/Entity/Traits/ directory. At 1 star and 0 dependents, the safe PM call is "copy the six trait files," not "add a Composer require."

Look elsewhere (or write it yourself) when:

• You need maintained dependencies with security patching — 2020 last release and no dependents means no upstream support and effectively no community review.
• You are on Laravel, or on Symfony but not using API Platform.
• You need configurable soft-delete semantics, restoration APIs, cascade rules on delete, or GDPR-grade purge workflows. The README's hardDelete=false example is the ceiling of what's documented here.
• You need ODM-and-ORM parity with tests, docs, or migration guides — the package points to a sibling repo (api-platform-test) as the only evidence of validation.
• Your team would spend more time auditing an abandoned dependency than writing six short traits.

How to Pitch It (Stakeholders)

One line: A tiny, unmaintained Symfony/API Platform helper that bundles six standard entity traits (ID, timestamps, soft delete) — useful as a template we copy, not as a dependency we adopt.

To executives: This is not a buy decision, it's a borrow decision. It costs nothing and reduces boilerplate on a small set of API entities. It carries no licensing cost and no adoption risk provided we vendor the pattern internally rather than depending on the package — the project has one star, zero dependents, and hasn't shipped since April 2020, so there is no support path. Recommendation: replicate the six traits in-house (~half a day of engineering) and keep an eye on our own maintenance instead of someone else's. It also does not apply if we standardize on Laravel — this is Symfony/API Platform tooling.

To engineering:

• What it gives you: OrmIdentificatorTrait, OrmTimestampableTrait, OrmSoftDeletableTrait plus ODM equivalents — i.e., $id, $createdAt/$updatedAt, $deletedAt conventions.
• What it requires: stof/doctrine-extensions-bundle configured with softdeleteable: true and timestampable: true, plus @Gedmo\SoftDeleteable annotations on the class. The traits are inert without that bundle.
• What it does not give you: config knobs, restore endpoints, cascade behavior, tests, or migration guidance.
• Proposed action: spend half a day reproducing the trait files under our own namespace, keep the Gedmo wiring, and document the hardDelete: false decision explicitly. If we'd rather take the dependency, it's a one-line composer require — but we should log it in the risk register as unmaintained and pin it.
• Verification step before committing either way: confirm the six traits actually match our field naming and serialization groups; the README shows a single example class and nothing about API Platform normalization, so expect to adjust.