Weave Code
Boolean Softdeletes Laravel Package
laravel-json-api/boolean-softdeletes
Adds boolean soft delete support to Laravel JSON:API resources. Rather than a deleted_at timestamp, models are flagged with a boolean column, so trashed records stay visible and filterable through your API while normal queries still exclude them.
Laravel JSON:API integration for the yocto/illuminate-database-softdeletes package
Frequently asked questions about Boolean Softdeletes
- What is laravel-json-api/boolean-softdeletes used for?
- It is a thin adapter that teaches laravel-json-api to interpret boolean soft-delete state produced by yocto/illuminate-database-softdeletes. Instead of a deleted_at timestamp, models are flagged with a boolean column, so trashed records stay visible and filterable through your API while normal queries still exclude them. It only adds value if your application already uses both laravel-json-api and the Yocto trait.
- How do I install and configure it in a Laravel JSON:API app?
- Composer-install both halves, swap the Yocto trait onto each model, add an additive boolean column with a default and index, and apply the package's schema concern per schema. The README itself advises verifying namespaces against vendor source rather than trusting the docs. A good first spike is a GET /api/posts?filter[trashed]=with request plus a PATCH restore round-trip.
- Does it work with Laravel's native SoftDeletes or only boolean soft deletes?
- Only boolean soft deletes. Teams on Laravel's built-in SoftDeletes are looking at a schema migration and a semantics change, not a drop-in integration. If you are on native soft deletes and not under measured performance pressure, skip this package and revisit only if both prerequisites become true.
- Which versions of Laravel and laravel-json-api are supported?
- There is no evident CI matrix, so the compatibility picture across PHP, Laravel, laravel-json-api, the Yocto package, and database drivers is unclear. Verify versions against vendor source and test inside your own application before committing. With 3 stars, zero dependents, and a single maintainer, treat support as unproven rather than guaranteed.
- How does filter[trashed] behave with a boolean deleted column?
- The package translates the boolean state into JSON:API semantics, supporting the filter[trashed] values with and only, plus restore and force-delete actions and route binding of trashed records. The exact mapping onto withTrashed() and onlyTrashed() scopes should be confirmed against the pinned version. Write tests that assert each filter value returns the expected records.
- Will route binding resolve trashed records so restore does not return a 404?
- Resolving trashed records for restore is part of the package's intended behavior, but you should verify it in your own application rather than assume it. Add explicit tests for restore and force-delete round-trips, including authorization on trashed retrieval. These are exactly the behavioral edge cases most likely to break in a thin adapter.
- What are the risks of switching from deleted_at to a boolean deleted column?
- A boolean flag loses who deleted the record and when, so any auditable delete history still requires a separate audit table regardless of this package. Behavioral edge cases include restore, force-delete, relation cascades, unique constraints, and authorization on trashed retrieval. The data migration itself is real work: additive column, backfill from deleted_at, dual-write or shadow-read, scope and policy updates, then cut over.
- Is this package production-ready and actively maintained?
- Adoption signal is very low: 3 stars, zero dependents, a single maintainer, and no evidence of production use. There is also transitive dependency risk through the Yocto package, whose own maintenance cadence and default column naming vary by version. Apache-2.0 removes the license cost but not the ownership cost if upstream goes quiet.
- When should I choose boolean soft deletes over a timestamp?
- The justified case is high-volume tables where an indexed boolean beats a nullable timestamp index and is deleted is the only question the query layer asks. Outside that intersection of laravel-json-api plus the Yocto trait, the package delivers zero value. Fit is strictly conditional, so adopt it only where both prerequisites are already chosen or actively justified.
- What alternatives exist if I do not adopt this package?
- Stay on Laravel's native SoftDeletes and skip the schema change unless you have measured performance pressure. You can also write the small amount of JSON:API glue yourself if you need boolean semantics with a stack you control. Either way, plan a separate audit table if delete history matters to your application.
Weaver
How can I help you explore Laravel packages today?