- What is roadrunner/api-dto used for?
- It provides pre-generated PHP classes that mirror RoadRunner's protobuf API, so PHP workers can encode and decode RPC messages to the rr server. The classes are infrastructure code for the RoadRunner transport and worker packages. Application developers normally do not import them directly.
- Do I need to install roadrunner/api-dto in a Laravel app?
- Only if you explicitly use RoadRunner RPC features or build a custom transport or interceptor. In a standard Laravel Octane setup with the RoadRunner driver, it is pulled in transitively by the RoadRunner worker packages. Do not add it to your app's composer.json just for API DTOs.
- Is roadrunner/api-dto a general DTO library for Laravel APIs?
- No. Despite the DTO name, these are generated protobuf message classes for the RoadRunner wire protocol, not request-validation or attribute-casting DTOs for your application. For app-level API DTOs use a package like spatie/laravel-data or hand-written DTOs. Using roadrunner/api-dto for HTTP request payloads is not its purpose.
- How do I install roadrunner/api-dto?
- Use Composer: composer require roadrunner/api-dto. In most Laravel Octane projects you should not run that command; let the RoadRunner transport package select the version. If you must pin it, check composer why roadrunner/api-dto and align with the rr binary version.
- Does roadrunner/api-dto support Laravel 10 and Laravel 11?
- The package contains plain PHP classes and has no Laravel service provider, so its Laravel compatibility is indirect. Support depends on the PHP version and the RoadRunner transport packages you use. Check those packages' constraints for the exact Laravel version support.
- Can I use roadrunner/api-dto with PHP-FPM or Swoole?
- Practically no. The DTOs exist to speak the RoadRunner RPC protocol to the rr binary; they add no value in FPM/nginx or Swoole-based Octane deployments. If you are not running RoadRunner, you should not require this package.
- What changed in roadrunner/api-dto 2.1.0?
- Version 2.1.0 is a Composer package rename plus a README refresh; the protobuf and DTO payloads are byte-identical to 2.0.0. That means no wire-format decode risk, but the rename is breaking for explicit requires and lockfiles that still name the old package. Treat it as a major dependency-identity change.
- How do I avoid installing both the old and new roadrunner/api-dto names?
- Do not add an explicit require while upstream RoadRunner packages still depend on the old name. Run composer show and composer why to confirm only one package provides the generated classes. If both names resolve, Composer can map two PSR-4 roots to the same class names, causing nondeterministic autoload behavior.
- Should application code import RoadRunner DTO classes directly?
- No, in normal Laravel applications you should treat these classes as internal to the RoadRunner transport. Direct imports couple your code to a generated API and to the rr binary version. Only custom RPC services, interceptors, or Go/PHP plugins that speak the RoadRunner protocol should use them directly.
- How do I test a Laravel app that depends on roadrunner/api-dto?
- You rarely test these generated DTOs directly; test your own RPC service or interceptor against a running rr server or a mocked transport. For Octane smoke tests, verify that the worker boots and that the installed DTO version matches the RoadRunner binary. Unit tests for application controllers should not need to touch these classes.