Yandex Market Products Laravel Package

Product Decisions This Supports

• Build vs. buy for a Yandex Market product feed: This package answers a narrow slice of that question — it supplies the product-catalogue layer (entities, mappings, Doctrine schema, sync scaffolding) for a Yandex Market integration, under MIT. It removes boilerplate but not business logic, so the real decision it informs is "buy a head start vs. commission a bespoke connector," not "buy the integration."
• Platform standardization: Adopting it is implicitly a bet on the BaksDev/Symfony + Doctrine toolchain (bin/console, doctrine:migrations:diff, baks:assets:install). Despite being framed as a Laravel/PHP package, the install and migration commands are Symfony/Doctrine conventions. A PM should treat this as a framework decision, not a utility-dependency decision, and correct the "Laravel" framing before it reaches a proposal.
• Roadmap gating for Russia/CIS expansion: If Yandex Market is a strategic channel, this compresses a v1 catalogue-sync milestone. If it's a secondary channel, scope it as a one-sprint spike and keep it out of the committed roadmap.
• Scope-shaping and budget lines: It makes explicit what is included (product entity, schema, mapping, migration path, a PHPUnit test group) versus what must be built internally (credentials/config contract, rate limiting, retries, partial-failure recovery, batching for large catalogues, observability, YML/multi-language output).
• Risk-register and dependency-governance input: Zero stars, zero dependents, single maintainer, Russian-only README, empty release notes, and a future-dated release (2026-08-07) belong in the vendor-risk log with a named owner — regardless of whether you adopt.
• Not supported: Decisions about other marketplaces (Amazon, eBay, Ozon), Yandex Direct/advertising, recommendations, or pricing engines.

When to Consider This Package

Consider it when:

• The application is already, or is deliberately moving to, the BaksDev ecosystem (Symfony-style stack, Doctrine ORM, bin/console conventions). Inside that context it is the natural fit and eliminates duplicated entity/schema work.
• Yandex Market is a top-tier sales channel and the immediate need is a product-data foundation plus migrations, not a polished, documented, SLA-backed integration.
• PHP 8.4+ is already your runtime target — this is a hard floor, and upgrading PHP is a prerequisite project, not a package side effect.
• You are prepared to vendor or fork the code, own the tests, and treat the maintainer as a single point of failure.
• The work is framed as a 2–4 week time-boxed spike feeding a build-vs-buy call, not a committed production dependency.

Look elsewhere when:

• You are on Laravel with Eloquent. Doctrine entities and migrations do not port to Eloquent; retrofitting means running dual ORMs or rewriting the persistence layer — i.e., owning a fork. Verify the stack assumption before this enters any proposal.
• You need a documented configuration or credentials contract (.env, secret manager, sandbox vs. production switching). The README is Russian-only and covers installation steps only.
• You need large-catalogue performance evidence (100k+ SKUs), batched/chunked export, rate-limit handling, or retry/queue behaviour — none is evidenced.
• Community support, SLAs, or maintenance guarantees are procurement requirements, or you need a readable changelog to assess breaking-change surface.
• Your market is outside Russia/CIS, or Yandex Market is a minor channel where a commercial connector — or a scheduled export — is cheaper than owning a fork.
• You are not yet on PHP 8.4 and cannot justify the upgrade for one integration.

How to Pitch It (Stakeholders)

To executives: This is a zero-licence-cost, MIT-licensed module that supplies the product-catalogue half of a Yandex Market integration for shops on the BaksDev/Symfony stack. It is worth a short, time-boxed evaluation — not an immediate commitment — because it could remove weeks of entity and schema groundwork on a priority Russian sales channel. The caveats are material and should be stated plainly: no visible community adoption, one maintainer, documentation only in Russian, empty release notes, and a PHP 8.4+ requirement. The pitch is "buy a head start, budget to own the code." Gate any production use on a 2–4 week spike that proves (a) it boots inside our actual stack, (b) sync is correct, and (c) catalogue-size performance is acceptable.

To engineering:

• What we get: product entities, Doctrine migrations, asset/config publishing, and BaksDev console wiring for Yandex Market catalogue data — the boilerplate layer only.
• What it costs us: a hard dependency on baks-dev/yandex-market, Doctrine ORM, PHP 8.4+, and the BaksDev lifecycle. Assume we fork it; budget tests, error handling, retries, observability, and a path off the PHP pin.
• Spike must answer: (1) does composer require baks-dev/yandex-market baks-dev/yandex-market-products resolve and boot in a representative copy of our app — Symfony console vs. Artisan is the deciding factor; (2) does the generated Doctrine diff stay strictly additive (if it alters existing product tables, stop and re-scope as a fork); (3) does it handle our largest catalogue with acceptable sync duration; (4) are credentials/shop IDs configurable without reading source; (5) are retries, rate limits, and partial-failure recovery present or absent; (6) does the sibling package pin a specific Yandex API version, and who absorbs Yandex's breaking changes.
• Recommendation: spike behind a feature flag, hide the module behind an internal MarketplaceCatalogExporter interface so it can be swapped, pin both BaksDev packages to exact versions with a committed lockfile, and log the 0-star/single-maintainer risk in the dependency register with a named owner.