Ozon Support Laravel Package

Getting Started

Read this before running composer require. baks-dev/ozon-support is not a Laravel package. It is a satellite module of the BaksDev ecosystem — Symfony-style console tooling (bin/console), a baks: command namespace, a PHP 8.4 floor, and almost certainly Doctrine entities behind it. There is no ServiceProvider, no config/ozon-support.php, no facade, no publishable assets. Laravel's package discovery has nothing to discover.

So "getting started" splits into two honest paths.

Path A — evaluate the package itself (half a day, disposable):

1. Check your PHP floor first. php -v must be 8.4+. Laravel 11/12 run fine there; a legacy Laravel 9/10 image likely does not.
2. Install into a scratch directory or a throwaway branch, not your app: composer require baks-dev/ozon-support.
3. Read vendor/baks-dev/ozon-support/composer.json immediately. That single file answers the questions the README does not: which baks-dev/* packages are hard requires, whether it pulls Doctrine, and whether it declares a Symfony bundle class.
4. Find the command class behind baks:users-profile-type:ozon-support and the migration/schema it writes. That is the entire functional surface of this package.
5. If you have a BaksDev app available, run php bin/console baks:users-profile-type:ozon-support and diff the schema. Otherwise stop here — you have now read the whole module.

Path B — the realistic Laravel first use case. Take the concept, not the dependency. The package registers an "Ozon Support" profile type so users/agents/tickets can be typed and segmented. In Laravel that is a backed enum plus a column plus a cast:

enum ProfileType: string {
    case OzonSupport = 'ozon_support';
}

First real use case: a support agent or account can be filtered as Ozon-facing, so ticket routing, SLA reports, and admin lists can scope to it. Ship that in a migration and a model cast in an hour, with zero new dependencies.

Implementation Patterns

Pattern 1 — Spike-then-decide (recommended default). Timebox the package to a branch: install, run the profile-type command in a BaksDev-capable environment, capture the resulting schema in a written note. Decide from evidence, not from the README. Most Laravel teams will end this spike by closing the branch.

Pattern 2 — Port the concept. If the spike confirms the capability is "label users as Ozon support," reimplement locally: enum + $table->string('profile_type')->index() + cast + a query scope + a factory state + a seeder. This gives you the same leverage with no vendor coupling and no PHP 8.4 gate.

Pattern 3 — Wrap, don't leak (if you adopt). If you genuinely must consume the vendor code, bind it behind your own interface so domain code never references baks-dev namespaces:

// app/Contracts/OzonSupportProfiles.php
interface OzonSupportProfiles { public function typeKey(): string; }

// app/Providers/AppServiceProvider.php
$this->app->bind(OzonSupportProfiles::class, BaksOzonSupportAdapter::class);

Removal then becomes a one-class change instead of a grep across the codebase.

Pattern 4 — Bridging into Artisan (usually a mistake). Running the Symfony command inside Laravel means a custom Artisan command wrapping the Symfony command class, plus Doctrine alongside Eloquent for the schema it touches. Two ORMs on one database is a maintenance tax with no payoff here. Only consider it if the package turns out to own data you cannot reimplement.

Day-to-day workflow tips once the concept is in place:

• Drive routing off the enum, not off string literals scattered through controllers.
• Expose scopes (User::ozonSupport()) so reports and admin filters stay declarative.
• Add a factory state (->ozonSupport()) so tests are readable and seeding is repeatable.
• If actual Ozon communication is needed later, that lives in a job/HTTP client layer — this package provides none of it, so keep the boundary clear from day one.

Version discipline if adopted: pin the exact version, commit composer.lock, and diff source on every bump. Floating ^7.x against releases whose notes are just the version string repeated is not a defensible posture.

Gotchas and Tips

• No service provider, no discovery. Nothing auto-registers in Laravel. Any expectation of php artisan vendor:publish is misplaced.
• baks:users-profile-type:ozon-support is not an Artisan command. It requires the BaksDev users subsystem and Symfony's console kernel. In a vanilla Laravel app it simply does not exist.
• Silent inertness. Skip the registration command in a BaksDev app and the feature is just absent — no exception, no log line. The failure mode is "nothing happened," which is easy to mistake for success.
• Opaque releases. v7.4.13 through v7.4.17 are documented only as the version number. There is no bugfix/breaking-change signal, and 7.4.16 shipping with a 2026 date suggests lockstep monorepo versioning rather than semver for this module. Budget coordinated bumps across the whole baks-dev/* cohort, not a single-package upgrade.
• PHP 8.4 floor. Verify CI images and container base images before you plan anything. A next PHP major landing could gate the entire cohort.
• Doctrine-shaped schema. BaksDev runs on Doctrine; expect entity mappings and migration classes rather than Eloquent migrations. Confirm in composer.json before you assume Eloquent interop.
• Russian-only, fourteen-line README. Onboarding material for non-Russian-reading engineers is a real, if small, cost — write your runbook during the spike or it will never exist.
• Tests are opt-in. vendor/bin/phpunit --group=ozon-support (not bin/phpunit) is a tagged group in their suite. It is not wired into your pipeline, and there is no visible CI badge. Treat it as evidence of unit coverage, not of integration verification — nothing here is tested against a live Ozon surface.
• Zero stars, zero dependents, one maintainer. If you adopt, you own the code from day one. MIT makes a private fork trivial and is the realistic steady state; that is also the strongest argument for Pattern 2.
• Scope hygiene — the highest-value tip. Do not let this install be logged upward as "Ozon marketplace integrated." There is no OAuth2 flow, no seller API client, no orders, inventory, Ozon Pay, delivery, or webhooks in the artifacts. If someone needs those, that is a separate, larger piece of work.
• Extension points: essentially none documented. Your wrapper (Pattern 3) is the extension point. Plan accordingly.
• Debugging aids: composer why baks-dev/ozon-support to see who dragged it in, composer show -a baks-dev/ozon-support for declared requirements, and a straight read of vendor/ — for a module this size, the source is the documentation.