- Is metglobal/dto-bundle a Laravel package?
- No. It is a Symfony bundle built around Symfony's bundle registration, dependency injection extension, compiler passes, and services.yaml conventions. Laravel has no equivalent runtime for those mechanisms, so most of the package's wiring is inert in a Laravel application. Only a small framework-agnostic DTO core might survive porting.
- Can I install metglobal/dto-bundle in Laravel 10, 11, or 12?
- It is not recommended. The package targets older PHP 7.x and Symfony 3.4/4.x constraints, so composer require will likely fail or force a resolution that downgrades symfony/* packages shared with Laravel. That is a framework-wide regression, not a package-level issue. Stop if resolution requires downgrading illuminate/* or shared Symfony components.
- What does metglobal/dto-bundle actually do?
- It provides a Symfony bundle for working with data transfer objects, mainly converting request or array data into typed PHP objects rather than loose arrays. The framework-agnostic slice is likely an abstract DTO base class with fromArray/toArray, type coercion, and mapping metadata. That is a small fraction of what the bundle nominally offers once the Symfony wiring is removed.
- Is metglobal/dto-bundle still maintained?
- No. The repository is archived, has 2 stars and 0 dependents, and shows no release cadence or issue triage. There is no security advisory path or CVE response process. Treat it as abandoned rather than merely low-activity.
- What are the best Laravel alternatives to metglobal/dto-bundle?
- For typed hydration and nested mapping, spatie/laravel-data is the maintained Laravel-native equivalent. For minimal cases, PHP 8.1+ readonly classes plus hand-written fromArray methods cover the need with zero dependency surface. Use Laravel FormRequests and Validator for validation, and JsonResource for serialization shaping.
- Does metglobal/dto-bundle support PHP 8.1+ and modern Laravel versions?
- There is no evidence of support. Dependency constraints almost certainly target PHP 7.x and Symfony 3.4/4.x, and the package has had no releases to add PHP 8.1, 8.2, or 8.3 support. Running it against Laravel 10/11/12 on PHP 8.1+ is untested and likely to conflict. Pin and audit any fork explicitly rather than inheriting upstream constraints.
- How do I install metglobal/dto-bundle?
- You would normally run composer require metglobal/dto-bundle, but for a Laravel application do not install the Symfony bundle directly. If a business constraint forces use, fork the repository into an internal namespace, strip the Symfony bundle and DI layer, retain only the DTO core, and publish it as an internal Composer package. Reconcile the fork's constraints against your current composer.lock before writing code.
- What security risks come with metglobal/dto-bundle?
- The main risk is abandonment: archived status means no CVE response, no PHP minor support, and no security advisory path. The MIT license is permissive and unproblematic; the lack of maintenance is the issue, not the legal terms. An unmaintained dependency in the request-handling data path is a high-severity supply-chain concern.
- Can I use metglobal/dto-bundle without Symfony?
- Only the framework-agnostic core might be usable outside Symfony, likely the abstract DTO base class with fromArray/toArray and coercion logic. The Bundle subclass, DI extension, compiler passes, and services.yaml conventions have no runtime in Laravel. Extracting that core requires a fork and an audit for hidden annotation or serializer dependencies.
- What should I do if a client or contract requires metglobal/dto-bundle?
- Do not adopt the upstream bundle in a Laravel codebase. Fork it internally, strip the Symfony integration layer, add PHP 8.2/8.3 CI, assign an owner on the on-call rota, and define an exit ramp if the fork stalls. Also confirm whether the requirement is contractual or incidental before committing to a long-term fork.