Descommarket Common Laravel Package

Product Decisions This Supports

• Build-vs-buy on shared domain code. A "common" package like descommarket_common is typically the extraction layer for primitives every service in a marketplace needs — enums for order/listing states, money and currency value objects, address and geo helpers, base Eloquent models, traits for audit/timestamps, and service-provider wiring. The decision it informs is whether to keep duplicating that logic per repo or consolidate into a versioned dependency.
• Marketplace domain-model consistency. In a multi-sided marketplace, inconsistent representations of a listing, an offer, or a payout are where bugs and reconciliation failures come from. Adopting a shared package is a way to decide once on the canonical shape of those concepts instead of letting each squad re-litigate them.
• Roadmap sequencing for platform work. If two or more services are about to touch pricing, fees, or order state, that is the moment to invest in a shared library — not after the third implementation. This package is a candidate vehicle for that platform investment.
• Buy-vs-build for commoditized utilities. If the package's content is mostly money formatting, slug generation, or enum helpers, the honest PM answer is often "use brick/money + spatie/laravel-data and stop maintaining a bespoke common lib." This package is a prompt to make that call explicitly.
• Dependency and upgrade-cost budgeting. Every shared package is a recurring tax: PHP/Laravel version bumps, security patches, coordinated releases. The decision it supports is whether the coupling it creates is cheaper than the duplication it removes.

When to Consider This Package

Adopt it when all of the following hold:

• You are already inside the descom/market ecosystem, or you are explicitly reusing its domain conventions. The namespace and description signal an internally-scoped library, not a general-purpose one.
• You have two or more applications or services that would otherwise copy the same marketplace primitives.
• You can read the source and are willing to own it as a fork or vendored dependency — 0 stars, 0 dependents and a generic "descommarket common" description mean there is no third-party support contract, no meaningful issue history, and no community to absorb your bug reports.
• You are comfortable pinning a version and testing upgrades yourself, including Laravel major-version compatibility.

Look elsewhere when:

• You need a public, documented, maintained foundation for a new product. Reach for brick/money, spatie/laravel-data, spatie/laravel-package-tools, or laravel/framework primitives directly instead.
• Your team is not on the descom domain model. Importing another company's shared conventions into your bounded contexts creates coupling you did not choose.
• You need SLAs, security advisories, or CVE response. Zero stars and zero dependents means zero external eyes on the code.
• The only thing you'd gain is a handful of helper functions. The coordination overhead of a shared package exceeds the value at that size — copy the 40 lines instead.
• The package's release metadata looks unreliable. The listed release date (2026-04-08) is in the future relative to normal release cadence, which is a signal to verify tags, changelog, and CI status by hand before letting it into a production dependency graph.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small internal shared-code library for a marketplace application — the kind of package that holds the "one true definition" of things like order states and pricing rules so different teams don't implement them differently. It has no external users, no community, and no support, so it is not a strategic asset and not a risk we should take on speculatively. The recommendation is: do not adopt for new work unless we are already in that ecosystem. If we need shared marketplace primitives, we should fund a small, owned internal package with an explicit owner and a versioning policy — a two-to-three week platform investment, not a dependency decision.

For engineering: Treat this as reference material, not a dependency. Read it, mine it for domain conventions if we're aligning with descom, and fork only if we're prepared to own it. Before any adoption: inspect the source for framework-version constraints, check whether the release tags and changelog are real, confirm test coverage exists, and confirm a named owner on our side. If the answer to any of those is no, we vendor the ~200 useful lines and move on.

The decision we need: Either (a) approve a small, owned internal common package with a real maintainer and a deprecation policy, or (b) confirm we stay on general-purpose ecosystem packages and accept some duplication. Doing nothing is a choice for (b) by default — worth stating out loud.