Pbjc Laravel Package

Product Decisions This Supports

• Schema-first / contract-first architecture. pbjc compiles a single pbj schema (a JSON-format IDL) into PHP classes, JSON Schema for runtime validation, and JavaScript for client consumption. It directly supports the decision "do we define API and event contracts once and generate code, rather than hand-write DTOs in every language?"
• Build vs. buy for codegen tooling. It is Apache-2.0 and small enough to vendor. The realistic decision it enables is "adopt and fork" rather than "license a schema registry / codegen platform" — useful when you want contract generation without a commercial dependency.
• Event and message contract governance. gdbots' home turf is message buses; generating typed PHP payloads plus JSON Schema validators for events and commands reduces producer/consumer drift and makes contract tests cheap.
• Polyglot surface reduction. One definition yields PHP (backend), JS (frontend) and JSON Schema (validation, docs, contract tests). This backs roadmap items for a published API/SDK or a typed event bus without funding a per-language modelling effort.
• Roadmap input. If the org is moving toward a typed event bus or a public API with published schemas, this is a low-cost way to prototype the contract pipeline before committing to a heavier standard (protobuf/OpenAPI).

When to Consider This Package

Consider it when:

• You are already inside the gdbots/pbj ecosystem, or you have pbj-format schemas you need to compile.
• Your stack is PHP-centric but you also need JS artefacts and JSON Schema from the same source.
• You can vendor or fork it and own the maintenance — a small platform team can read and patch the compiler.
• The output is build-time only (a dev dependency), so a dormant upstream carries less runtime risk than an abandoned library on a hot path.

Look elsewhere when:

• You need a maintained, security-reviewed dependency in production. Last release was 2019, with 0 stars and 0 recorded dependents — you would effectively be the only user.
• You are not already committed to pbj schemas. Switching cost is high and ecosystem signal is weak; prefer protobuf/gRPC, OpenAPI Generator, or mature PHP DTO tooling (Symfony Serializer plus generated DTOs, spatie/data-transfer-object, cebe/php-openapi), all of which have active maintainers.
• You need support, SLAs, or a community to ask questions of. There is none here.
• Your team has no appetite for owning a compiler/fork — it then becomes a hidden maintenance tax.

How to Pitch It (Stakeholders)

To executives: This is a small, permissively licensed (Apache-2.0) schema compiler that turns one data-contract definition into PHP classes, JSON Schema and JavaScript. It could cut hand-written boilerplate and cross-team drift for our API and event contracts. The catch: it is effectively unmaintained (no release since 2019, negligible adoption), so we would treat it as vendored source we own, not a vendor dependency. Recommendation: worth a short spike and a fork-and-pin decision, not a strategic bet.

To engineering: Single source of truth for payload types; generated PHP, JS and validators remove the "did the frontend and backend agree?" class of bug. It is a build-time tool, so blast radius is contained. Risks: zero upstream activity, no security patching, sparse docs and examples — budget a few days to read the source and stand up a tested fork before relying on it. If we do not want to own a compiler, standardise on protobuf or OpenAPI codegen instead.