We are currently using beacon-hq/bag (formerly dshafik/bag) for our DTOs / Value Objects, and while I'm pretty satisfied with its feature set, it's been pretty much unmaintained, and we already have to patch it locally. I see a few ways forward:
-
Fork Bag (soft fork): we could maintain a fork that incorporates just the necessary fix we're currently applying as a patch, plus whatever bug fixes we find along the way, keeping the current feature set and API intact. This is the quickest short-term solution, but I wouldn't call it a permanent fix.
-
Fork Bag (hard fork): go our own way with Bag, remove whatever features we don't need, add whatever we want, make it a new thing, maybe even put it on packagist. I don't mind doing a total-rewrite fork in principle, but I'm not sure I want to be a vendor of a public DTO package though: it's arcane fiddly work, and every tiny change will end up breaking someone's workflow downstream.
-
Use an alternative package. Viable contenders include:
- crell/serde
- cuyz/valinor
- zolex/vom (symfony-based, but not a problem)
I am specifically ruling out spatie/laravel-data: it's very much tied to Laravel, has lots of overhead, and uses objectionable amounts of magic.
While the packages listed above are all of the "mapper" style in that they don't require a base class, I'm not entirely opposed to inheriting all DTOs from a single base if it avoids unhealthy contortions just to make it fit into a trait -- it's not like DTOs have to be generally reusable outside of the app framework anyway, and if a base class means avoiding having to sprinkle attributes onto every property, so be it. The most likely scenario in my mind involves a "thin" base or trait that cooperates with a mapper implementing most of the logic, but we should keep an open mind.
We are currently using beacon-hq/bag (formerly dshafik/bag) for our DTOs / Value Objects, and while I'm pretty satisfied with its feature set, it's been pretty much unmaintained, and we already have to patch it locally. I see a few ways forward:
Fork Bag (soft fork): we could maintain a fork that incorporates just the necessary fix we're currently applying as a patch, plus whatever bug fixes we find along the way, keeping the current feature set and API intact. This is the quickest short-term solution, but I wouldn't call it a permanent fix.
Fork Bag (hard fork): go our own way with Bag, remove whatever features we don't need, add whatever we want, make it a new thing, maybe even put it on packagist. I don't mind doing a total-rewrite fork in principle, but I'm not sure I want to be a vendor of a public DTO package though: it's arcane fiddly work, and every tiny change will end up breaking someone's workflow downstream.
Use an alternative package. Viable contenders include:
I am specifically ruling out spatie/laravel-data: it's very much tied to Laravel, has lots of overhead, and uses objectionable amounts of magic.
While the packages listed above are all of the "mapper" style in that they don't require a base class, I'm not entirely opposed to inheriting all DTOs from a single base if it avoids unhealthy contortions just to make it fit into a trait -- it's not like DTOs have to be generally reusable outside of the app framework anyway, and if a base class means avoiding having to sprinkle attributes onto every property, so be it. The most likely scenario in my mind involves a "thin" base or trait that cooperates with a mapper implementing most of the logic, but we should keep an open mind.