Protobuf Plugin Laravel Package

Product Decisions This Supports

• Schema-first contract design across a polyglot stack. If we define .proto files as the single source of truth between a PHP app and Go/Java/Python services, we need a PHP code-generation path. This package is one candidate generator, so it informs the "how do PHP consumers get typed classes from the contract?" half of that decision.
• Serialization format choice for internal service calls. Protobuf vs. JSON/REST is a real fork in the road (payload size, schema evolution, codegen tooling, debugging ergonomics). Evaluating this package forces us to price the PHP-side tooling cost of the protobuf branch.
• Build vs. buy vs. generate. The alternative to a generator is hand-written DTOs and serializers, or generated-from-OpenAPI clients. This package represents the "generate from IDL" option and lets us compare maintenance burden against the alternatives.
• gRPC / contract-testing roadmap input. If gRPC is on the roadmap, the PHP generator choice becomes a blocker-level dependency; if gRPC is not on the roadmap, this package is irrelevant and we should say so explicitly rather than leaving it on a backlog.
• Vendor/toolchain risk register entry. With 57 stars, zero dependents, a last release of 2017-01-12, and a composite score of ~3.28 (opportunity 28), the decision it most directly supports is a negative one: documenting why we are not standardizing on it.

When to Consider This Package

Consider it only when all of the following hold:

• We are already committed to the protobuf-php/protobuf pure-PHP runtime (this plugin is a generator for that library, not for Google's google/protobuf runtime), and
• We are pinned to a legacy PHP 5.6/7.0-era toolchain where the modern toolchain is unavailable, and
• We need to regenerate classes in CI from .proto sources and cannot invoke protoc --php_out directly, and
• We accept a hard fork as a likely follow-on cost — the plugin is effectively unmaintained.

Look elsewhere — and we almost certainly should — when:

• New project. Use protoc with the built-in --php_out generator plus the official google/protobuf runtime, or grpc/grpc for gRPC. First-party, maintained, and covers proto3 optional, JSON mapping, and well-known types that a 2017 generator predates.
• PHP 8.x is in scope. Nine years without a release is a strong signal of incompatibility with modern PHP, typed properties, and current protoc plugin protocols. Validate before it appears in any estimate.
• We need performance. A pure-PHP runtime plus a generated-class layer will be materially slower than the C-extension-backed official runtime; if throughput matters, protobuf may lose to JSON on total cost.
• We just need typed DTOs. symfony/serializer, spatie/laravel-data, or OpenAPI-generated clients solve the same product problem with far better support and Laravel ecosystem fit.

The honest read: this is a reference implementation and fallback, not an adoption candidate. Its value to us is as a reading of how PHP protobuf codegen works and as a possible fork base if a legacy system traps us.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated protobuf-php/protobuf-plugin, a code generator that turns Google Protocol Buffers schema files into PHP classes. It is a small, MIT-licensed, single-purpose build-time tool with 57 GitHub stars, no downstream dependents, and no release since January 2017. Our recommendation is do not adopt it as a dependency; instead, if we pursue schema-first contracts between PHP and other services, use Google's official protoc --php_out generator and runtime, which are maintained and already support modern PHP. The strategic decision this unlocks is the protobuf-vs-JSON and gRPC-yes/no call — that decision is worth making this quarter; this package is not worth adopting to make it.

For engineering (the short version): It generates PHP classes for the protobuf-php/protobuf runtime, not for google/protobuf. It predates proto3 optional, well-known-type support, and PHP 8. Zero dependents means no community to absorb breakage. If a legacy service forces us onto it, budget for a fork and pin it; otherwise use the first-party generator. Ask: one-week spike, exit criteria = generates our three representative messages on our current PHP version and passes a round-trip serialization test. If it fails, we close the ticket with a documented "no" and move on to the JSON/vs/protobuf decision on its own merits.