Yandex Market Products Laravel Package

Getting Started

Before writing any code, verify the framing: this is a BaksDev/Symfony bundle with Doctrine ORM, not a Laravel package. It ships no service provider, no config/*.php merge, no vendor:publish tags, and no Eloquent models. There is no composer.json entry that Laravel's package discovery will pick up. If your application is a standard Laravel app on Eloquent, the realistic day-to-day use is either (a) a sidecar process that runs the BaksDev console against the same database, or (b) treating the source as a reference implementation whose entity shape you copy into your own Eloquent schema. Decide which before installing.

Minimal steps to get a working install:

1. Confirm PHP 8.4+ is your actual runtime (php -v). This is a hard floor, not a soft constraint — 8.2/8.3 will fail Composer resolution.
2. Install both packages in a scratch branch, pinned exactly:

   composer require baks-dev/yandex-market baks-dev/yandex-market-products
   

   Then edit composer.json to pin both to exact versions and commit the lock file. With zero dependents there is no community signal that a bad version pairing will be caught for you.
3. Publish config and file assets using the BaksDev console, not Artisan:

   php bin/console baks:assets:install
   

   In a Laravel host this means you need a bin/console entry point — typically Symfony\Component\Console\Application bootstrapped with the BaksDev kernel, or a container-based CLI in a sidecar.
4. Generate the Doctrine diff and read it before applying:

   php bin/console doctrine:migrations:diff
   

   Confirm every statement is CREATE TABLE / CREATE INDEX and namespaced to the module. Any ALTER or DROP against existing tables is a stop signal — that is a fork-level commitment.
5. Apply against a scratch database, verify rollback, then a staging copy.

Where to look first in vendor/baks-dev/yandex-market-products/:

• src/Entity/ — the product entity shape and its relations. This is your de facto documentation; the README is Russian-only and covers install commands only.
• src/DependencyInjection/ and any *Extension.php — the actual configuration surface, since there is no published config reference.
• migrations/ — what tables and columns land in your database.
• tests/ — the --group=yandex-market-products suite is the best available specification of intended behaviour: php bin/phpunit --group=yandex-market-products.
• The sibling baks-dev/yandex-market package — API client, credentials handling, endpoint switching all live there.

First use case to prove: export 50–100 SKUs end-to-end into a sandbox Yandex Market campaign, capturing the emitted payload. Do not start with pricing rules, multi-language YML, or queue/retry logic — none of that is in the box.

Implementation Patterns

Sidecar console bridge (recommended for Laravel hosts). Keep Laravel as the application and run the BaksDev module as a separate CLI process sharing the database. Wrap invocation in an Artisan command so scheduling lives where your team already looks:

// app/Console/Commands/YandexMarketExport.php
$process = Process::path(base_path('sidecar'))
    ->timeout(600)
    ->run('php bin/console yandex-market:export --since='.$since);

Log stdout/stderr to a Laravel channel; the module gives you no observability. Treat the process exit code as your only health signal.

Adapter, not replacement. Keep Eloquent as the system of record. Write a single adapter class that maps your Product aggregate onto the module's entity shape and owns all field translation (dimensions, currency, category, availability). Put it behind an internal interface (YandexProductExporter) so the module can be swapped for a hand-rolled exporter without touching call sites.

interface YandexProductExporter { public function export(Collection $products): ExportResult; }

Chunked export job. Never load the catalogue into memory. Dispatch a job per chunk and let Laravel's queue own retries, backoff, and failure capture — the package evidences no rate-limiting or retry behaviour of its own.

Product::query()->where('updated_at', '>', $since)
    ->chunkById(250, fn ($chunk) => ExportYandexChunkJob::dispatch($chunk));

Dual-ORM coexistence, if you must. If you choose in-process integration rather than a sidecar, register a separate Doctrine connection in config/database.php and run two migration toolchains. Keep the Doctrine connection read-mostly against module tables, never let it write to Eloquent-owned tables, and never wrap both in one transaction — the boundaries will not reconcile cleanly.

Read-model mirror. For dashboards, mirror the module's product/listing tables into an Eloquent read model refreshed on a schedule. This gives your team a familiar query surface and insulates reporting from Doctrine entity changes.

Credentials via Laravel config. The package documents no .env contract. Whatever the sibling package reads, resolve it in config/services.php from env() and inject it — do not scatter config/*.php files into the vendor tree or hard-code credentials in a published asset file.

Feature-flag the whole channel. Gate every entry point behind a flag. Given 0 stars, a single maintainer, and future-dated releases, assume you may need to disable the integration during an incident without a deploy.

Test the contract, not the vendor. Write fixture-based tests asserting the payloads your adapter produces against a recorded expected shape. The vendor's own group tests are useful as a smoke check but tell you nothing about Yandex API drift.

Gotchas and Tips

• artisan vendor:publish will not work. There are no publishable tags. baks:assets:install is a Symfony console command requiring bin/console and the BaksDev kernel. If you cannot stand that up, stop here.
• Doctrine's migrations:diff is destructive by default. Always run it, read the .sql, and check for DROP/ALTER. Use --dry-run where supported and diff against a restored production snapshot before touching anything real. This is the single most dangerous step in the install.
• PHP 8.4 is a project, not a package decision. Budget the upgrade separately; do not let a 2–4 week integration estimate absorb it silently.
• Release notes are empty across v7.4.11–v7.4.24, and 2026-08-07 is forward-dated. Verify real commit activity on the repository before trusting the tag as an activity signal. Pin exact versions in composer.json; do not use ^7.4.
• No documented configuration surface. Read DependencyInjection/ and the sibling package to discover how shop/campaign IDs and endpoints are set, and whether sandbox vs. production is switchable per environment. If it is file-based only, plan for a secret-manager shim.
• Debugging Doctrine in a Laravel app: enable the SQL logger on the module's connection, and clear the Doctrine metadata/proxy cache after any entity or mapping change (var/cache for Symfony, your own proxy directory in Laravel). Stale proxies manifest as "column does not exist" errors that look like migration failures.
• Memory: no batched/chunked export is evidenced. If you drive the export in-process, chunk and unset() aggressively; if you drive it via sidecar, pass a range and let the module stream — but verify with memory_get_peak_usage on a 10k-SKU trial before committing to a catalogue-size assumption.
• Extension points: prefer decorating the module's export service (Symfony DI decoration / container override) or overriding entity mappings in your own bundle over editing vendor/. If you find yourself editing vendor code, you have effectively forked — record that in the dependency register with a named owner.
• Regional constraint: Yandex Market is Russia/CIS only. The business case must justify the entire dependency on that one channel; there is no Amazon/eBay/general-marketplace value here.
• Exit plan: capture the generated schema (the migration SQL) into your own repo documentation. That artefact, not the package, is what lets you migrate off if the maintainer stops publishing.