Descommarket Common Laravel Package

Getting Started

1. Install and pin a version. This package has zero dependents and a vague description, so treat the source as the document of record. Require a tag rather than dev-main:

   composer require descom/descommarket_common:^1.0
   

   If it is not on Packagist, add the VCS repository entry and check composer.json for the PHP and illuminate/* constraints before installing.

2. Read the service provider first. Open vendor/descom/descommarket_common/src/ and find the provider registered in the package's composer.json under extra.laravel.providers. That file tells you everything that matters: which config keys are merged, whether migrations or translations are loaded, which contracts are bound, and which macros, commands, or facades are registered.

3. Publish before you assume. Run:

   php artisan vendor:publish --provider="Descom\DescomMarketCommon\DescomMarketCommonServiceProvider"
   

   Then inspect config/descommarket_common.php for defaults you must override in .env. Anything not published is being merged at runtime via mergeConfigFrom and cannot be cached correctly if you edit vendor/ files.

4. First use case. The realistic entry point for a "common" marketplace package is shared domain vocabulary: enums (order/payment/listing status), value objects or casts (money, slugs), and traits (HasUuid, Sluggable, scoping traits) that let multiple marketplace modules agree on the same shapes. Start by importing one enum into a single model cast or FormRequest rule, verify it renders and validates, then expand. Do not wire it into every model on day one.

5. Verify wiring. php artisan about should list the provider; php artisan config:show descommarket_common should show the merged config. If either is missing, autoload or discovery is broken — run composer dump-autoload -o and php artisan package:discover.

Implementation Patterns

Adopt shared enums as the single source of truth. Cast them on models and reuse them in validation and authorization:

protected $casts = ['status' => OrderStatus::class];

// FormRequest
'status' => ['required', Rule::enum(OrderStatus::class)],

This is the highest-leverage pattern: it removes duplicated string constants across marketplace services and makes match expressions exhaustive.

Compose traits rather than extending base classes. If the package ships a base model or base repository, prefer its traits composed into your own models. Extending a vendor base class couples you to its constructor and boot lifecycle, which is painful to escape later.

Bind against contracts, not concretes. If the provider registers interface-to-implementation bindings (pricing calculators, money formatters, marketplace resolvers), resolve them from the container so tests can swap fakes:

public function __construct(private MarketResolver $resolver) {}

Use the package's casts and helpers at the boundary. Money/currency casts should wrap Eloquent attributes only — pass plain integers or a domain object into jobs and API resources so queue payloads stay serializable and version-independent.

Publish assets into the app, not vendor. Copy migrations and config out with vendor:publish, commit them, and treat future package updates as a diff to review. With zero dependents there is no community signal on breaking changes, so you own the upgrade review.

Integration tip for modular marketplaces: if you have multiple modules (catalog, orders, payments) each with its own composer package, require this one in each and let Composer deduplicate. Keep the shared package free of app-specific config by overriding in each module's service provider.

Gotchas and Tips

• Zero dependents means zero field reports. There is no Stack Overflow corpus, no issue backlog to mine, and no third-party tutorials. Budget time to read src/ end to end — it is likely small enough to do in an hour — before you build on it.
• Future-dated release. The latest release is dated 2026-04-08. Confirm the tag actually resolves and that the tagged commit matches what you reviewed; a phantom or retagged release is a real supply-chain risk for a package nobody else depends on.
• Vague description is a signal. "descommarket common" gives no scope guarantee. Check for side effects in the provider: global scopes, Model::preventLazyLoading-style bootstrapping, DB::listen, or macro registration that silently changes framework behavior across your whole app.
• mergeConfigFrom vs publish. If you edit the config inside vendor/, config:cache will pick it up in local but your deploy pipeline may regenerate it. Always override via published config plus env vars, and prefix env keys (DESCOMMARKET_COMMON_*) to avoid collisions.
• Migrations loaded from the package run under the package's own ordering. If they reference app tables, foreign keys can fail on a fresh migrate. Publish them into database/migrations and rename timestamps so ordering is explicit.
• Helper function collisions. Common packages often ship global helpers via files autoload. If two packages define the same function name, you get a fatal error only at runtime, not at install. Grep the autoload files array.
• Debugging checklist: composer show descom/descommarket_common for the resolved version, php artisan package:discover -v, php artisan config:show, and a throwaway php artisan tinker call into whichever facade or enum you are testing. Clear bootstrap/cache between provider changes.
• Extension points to preserve: container bindings (swap implementations in AppServiceProvider), publishable config, and any Macroable classes. If you need behavior the package does not expose, prefer decorating its contract over forking — but given the maintenance profile, a fork pinned to your monorepo may genuinely be the safer long-term call.
• Pin the version in composer.lock and add a Dependabot/Renovate rule so upgrades arrive as reviewable PRs. With no dependents upstream, a breaking change will ship without a deprecation window.