Shopping Common Protos Laravel Package

Product Decisions This Supports

• Whether Google Shopping surfaces belong on the roadmap at all. This package is the type layer for Google's Shopping schema (google.shopping.type.* — price, shipping, availability, destination/channel enums). Installing it is only rational if "list and sell on Google" is already a committed initiative; it unlocks no capability on its own.
• Build vs. buy for feed management. It sits at the extreme "build" end: it gives you correctly-typed field definitions but no transport, no auth, no retry logic, no feed validation, no reconciliation loop. The real build cost is the pipeline around it, not this dependency.
• Catalog and pricing feature scoping. If the team is modeling per-market pricing, shipping tiers, or availability semantics, these protos are a credible reference schema — useful even as documentation for teams that ultimately call the REST API with hand-written DTOs.
• Multi-channel abstraction design. If the roadmap has 2+ commerce channels, adopting Google's canonical types as one adapter's contract reduces ambiguity in field naming and rounding/currency rules.
• Explicitly not supported: performance reporting, competitive pricing intelligence, or Merchant Center diagnostics. Those live in separate Merchant API packages, and conflating them with this one inflates the perceived value of adding it.

When to Consider This Package

Consider it when:

• You have already committed to the google/shopping-merchant-* PHP client family; this is effectively a shared transitive dependency and adding it directly just makes the contract explicit.
• You need byte-level schema parity with Google for validation, fixture generation, or contract tests, and hand-written DTOs have already drifted once.
• Your team already runs the protobuf/gRPC PHP runtime in production — the marginal operational cost is then near zero.
• You are writing an internal adapter where serialized Shopping types cross a service boundary.

Look elsewhere when:

• You only need to push products and prices. The REST Content API for Shopping plus google/apiclient or a thin HTTP client will get you there with far less tooling; this package will not make a single API call for you.
• There is no protobuf / grpc PHP extension in your deployment image. Adding native extensions to a Laravel container is a real, recurring tax for what is often a nightly batch job.
• You expect Laravel-native ergonomics — service provider, config publishing, facades, queue integration, typed Eloquent casts. None of that exists here and none of it is coming.
• You need vendor support, a changelog you can reason about, or issue triage. Release cadence is tied to Google's internal proto generation, and version numbers are not a signal of API stability in the semver sense.
• A feed-management SaaS is on the table — for most teams under meaningful catalog volume, buying beats maintaining proto pins and schema-drift alerts.

Read the adoption signals carefully. One star and zero dependents is not evidence of abandonment; it is an auto-generated googleapis artifact consumed transitively rather than starred. But it is also not evidence of a maintained product. Treat the low score as "no community safety net," and verify the release date against your own dependency resolution rather than trusting it at face value.

How to Pitch It (Stakeholders)

For executives: This is not a product decision, it is plumbing. The package is a set of auto-generated, Apache-2.0-licensed type definitions for Google's Shopping schema — no servers, no credentials, no data. The decision that matters is whether selling on Google surfaces is on the roadmap; if yes, this is a low-cost, low-risk component of that work. If no, it should not appear in any plan. Do not let a dependency install stand in for a strategy.

For engineering: It is a generated proto library, so budget for the runtime: protobuf (and likely grpc) extensions in the build image, version pinning, and a regeneration story when Google revises the schema. There is no Laravel integration by design — no provider, no config, no casts — so wrap it behind your own adapter interface rather than letting Google\Shopping\Type\* objects leak into domain code. Prefer consuming it transitively via the Merchant client packages unless you have a specific parity need.

Recommendation: Timeboxed spike, not a commitment. Prove one end-to-end feed push in a branch, measure the container and CI impact, and only then decide. Validate within the first two days that the runtime extensions install cleanly in your production image — that is the failure mode most likely to sink this, and it is cheap to test early.