- What is roadrunner-php/roadrunner-api-dto and what problem does it solve?
- It is a Composer package containing PHP Data Transfer Object classes generated from RoadRunner's protocol buffer API definitions. Instead of writing request and response message classes by hand, you use the generated DTOs to make typed RPC calls to RoadRunner plugins such as HTTP, Jobs, KV, Lock, Service, Status, WebSockets, Centrifugo, and Plugins. The package is a generated-contract layer, not a RoadRunner runtime or server.
- How do I install roadrunner-php/roadrunner-api-dto in a Laravel project?
- Install it with Composer using composer require roadrunner-php/roadrunner-api-dto. Composer will autoload the generated DTO classes, and there is no Laravel service provider or configuration file to publish. Because the v2.1.0 release notes describe a package rename, confirm the exact current package name on Packagist before changing production requirements.
- Does this package support Laravel, and which Laravel versions?
- The package is framework-agnostic and does not ship a Laravel service provider, facade, or config file. It works anywhere Composer autoloading is available, so it is not tied to a specific Laravel release cycle. Check the Packagist page for the required PHP version and make sure that matches your Laravel deployment target.
- Which RoadRunner plugins and RPC services do the generated DTOs cover?
- The DTOs are pre-generated from RoadRunner API protocol buffer files and cover Centrifugo, HTTP, Jobs, KV, Lock, Plugins, Service, Status, and WebSockets. These are the message types used when making RPC calls to the corresponding RoadRunner server plugins. The package does not implement the plugins themselves; it only provides the PHP message classes.
- Should roadrunner-php/roadrunner-api-dto be a require or require-dev dependency?
- Use require when your application code directly references the generated DTO classes to build RoadRunner RPC payloads. Use require-dev only when the package is needed for tooling, code generation, or test-only integration code. In either case, treat it as a contract dependency and avoid loading it on every request path unless your code actually needs the DTOs.
- How do I migrate from the old package name after the roadrunner/api-dto rename?
- The v2.1.0 release notes describe a rename to roadrunner/api-dto, and the technical assessment flags this as a breaking Composer identity change with no documented alias package. Update composer.json, the lockfile, and any use statements that reference the old namespace together, then run a full test suite. Confirm the exact target package name on Packagist before migrating, because the repository listing still shows roadrunner-php/roadrunner-api-dto.
- Is this package an alternative to spiral/roadrunner or the official RoadRunner PHP SDK?
- It is not a drop-in replacement for the official SDK. spiral/roadrunner is the RoadRunner PHP SDK and still bundles protocol handling, while this package only supplies generated DTO messages. Whether you need both depends on whether the SDK consumes these DTOs or whether your code makes direct RPC calls, and the release notes do not resolve that overlap.
- Can I regenerate the DTOs from the RoadRunner proto files myself?
- Yes. The README provides a generate.sh script that regenerates DTOs for all plugins into the generated directory. You need protoc version 3.15 or newer and the grpc_php_plugin compiled and available before running it. Regenerating lets you match a specific RoadRunner API revision, but you then own the generation and validation process.
- How do I test Laravel code that uses these RoadRunner DTO messages?
- The DTOs are plain PHP classes, so unit tests can instantiate messages, set fields, and assert serialization without a running RoadRunner server. For integration coverage, start a RoadRunner instance with the relevant plugin and make real RPC calls against it. In Laravel feature tests, mock the RPC client boundary so the suite does not depend on a live RoadRunner process.
- Is roadrunner-php/roadrunner-api-dto actively maintained and safe for production?
- It is published under the roadrunner-php GitHub organization, the same organization behind the official RoadRunner PHP SDK, and the README was refreshed in v2.1.0. Adoption is still low by the assessment's signal, the rename shipped as a minor version rather than a major, and there is no documented compatibility alias. The assessment also notes future-dated release tags, so pin an exact version in composer.json and confirm the maintainer list and proto regeneration cadence before relying on it in production.