Yandex Market Products Laravel Package

Technical Evaluation

Architecture fit baks-dev/yandex-market-products is a domain module, not an application framework or a standalone SDK. It plugs into the BaksDev platform — a Symfony-flavoured stack with a bin/console entrypoint, Doctrine ORM persistence, and an asset-install command convention — and depends on the sibling package baks-dev/yandex-market for the Yandex Market API client and shared abstractions. This package contributes only the product-catalogue half: entities, mapping/metadata for marketplace listings, and the schema to persist them. The "Laravel package" label in circulating material is inaccurate and must be corrected before it reaches a roadmap or an architecture review; a TPM who repeats it will send engineers down a Doctrine-vs-Eloquent rabbit hole. The honest framing is: fits a BaksDev application well, fits a vanilla Laravel application poorly, and is not a candidate for a greenfield Eloquent build.

Integration feasibility Feasibility is gated by a small number of binary preconditions that a TPM can and should check before allocating sprint capacity. The install path is composer require of the two packages, baks:assets:install, then a Doctrine migrations:diff/migrate cycle. There is no service-provider registration, no published configuration reference, and no documented .env contract for credentials, shop/campaign identifiers, sandbox-vs-production endpoints, or per-environment asset paths. That documentation gap is the single largest feasibility risk: a TPM cannot write an acceptance criterion for credentials handling or environment switching without a source read. Positives worth recording — MIT licence (no procurement friction), a tagged release series (7.4.11 → 7.4.24), and a dedicated PHPUnit group (--group=yandex-market-products) implying some internal test discipline. Absent: CI badges, coverage figures, integration tests against a mocked or live Yandex Market API, and any changelog body.

Technical risk

• Bus factor: 0 stars, 0 dependents, single-vendor namespace, empty release notes. On this package the maintainer is the vendor; losing them means owning the fork.
• Version opacity: consecutive releases with no changelog text mean a TPM cannot scope upgrade work or assert a security-fix cadence. Pin exact versions and commit composer.lock — there is no community to catch a bad combination.
• Platform lock-in: Doctrine entities and migrations do not port to Eloquent. Retrofitting into a Laravel app implies dual-ORM transactional complexity or a full persistence rewrite — reclassify from "adopt" to "fork and own" if that is our situation.
• PHP 8.4 floor: an aggressive minimum that makes the PHP upgrade a prerequisite project, not a package decision. Size it separately.
• Release-date anomaly: 2026-08-07 is ahead of normal current dates; verify against Packagist and git history rather than treating it as a liveness signal.
• Regional specificity: the business case rests entirely on Yandex Market as a Russia/CIS channel.
• Scope illusion: the package delivers boilerplate, not the integration. Rate limiting, retries, partial-failure recovery, pricing rules, multi-language YML, and observability are all outside the buy and must be budgeted as internal work.

Key questions

1. Are we genuinely a BaksDev/Symfony-Doctrine shop, or evaluating against vanilla Laravel? The answer changes this from a two-week install to a multi-month fork.
2. What is the verifiable commit history — last substantive code change, issue/PR triage, maintainer responsiveness?
3. How are credentials, shop IDs, and campaign IDs configured, and is there a path to our secret manager?
4. What catalogue scale must we support, and does the module batch/chunk exports without loading the full catalogue into memory?
5. Does baks-dev/yandex-market pin a Yandex API version, and who absorbs the breakage when Yandex revises its contract?
6. Is the entity schema documented well enough to migrate off if publishing stops?

Integration Approach

Stack fit State it plainly to the steering group: this fits a BaksDev/Symfony + Doctrine + PHP 8.4 application with an existing Yandex Market channel requirement. It does not fit standard Laravel/Eloquent, a multi-marketplace strategy, or a team that cannot run Doctrine alongside its current ORM. Everything downstream — staffing, timeline, budget — is conditional on a one-day dependency spike that answers a single question: does the pair of packages resolve and boot inside a representative copy of our application?

Migration path Frame this as additive, never as a migration. Sequence: (1) branch a disposable PHP 8.4 environment with Doctrine present; (2) install both packages and run baks:assets:install; (3) generate the Doctrine diff and review it before applying — confirm the new tables are additive and namespaced with zero alterations to existing product tables; (4) apply to a scratch database and validate rollback; (5) build a thin mapping adapter so our existing product records remain the system of record and the module's entities are a projection. If step 3 produces alterations to existing tables, halt — that is a fork-level commitment and needs re-scoping, not a workaround.

Compatibility Get three matrices in writing before any code merges: PHP version against our runtime fleet; Doctrine DBAL/ORM versions against what 7.4.24 implies; and the exact baks-dev/yandex-market core version required. Pin both packages exactly and commit the lockfile. If we run PostgreSQL, verify the generated migrations are dialect-safe — the README evidences nothing either way. Also confirm the test group actually executes green in our environment; "has tests" and "tests pass here" are different facts.

Sequencing Phase 0 (≈1 week, low cost): dependency spike plus a source read of the entity definitions and command surface, producing a written interface and config summary — this substitutes for the missing documentation and is the artefact the TPM needs. Phase 1 (2–3 weeks): sandbox integration on a 50–100 SKU sample exercising the full install-to-export path, capturing actual Yandex Market payloads and confirming the API contract version. Phase 2: a performance and failure-mode spike at realistic catalogue size (batch behaviour, memory ceiling, sync duration). Phase 3: productionisation — retries, rate limits, alerting, credential handling — all of which is ours to build. Gate each phase on a written exit criterion; do not let Phase 1 momentum become an implicit production commitment.

Operational Impact

Maintenance Assume we own this code. With one maintainer, no dependents, and opaque releases, the sustainable model is an internal fork or a vendored copy under our release cadence, with a named owner in the dependency register. Budget recurring effort for dependency bumps (PHP, Doctrine, Symfony) and for tracking Yandex API revisions — neither is covered by the package's release notes.

Support There is no support channel to escalate to: Russian-only README, install steps only, no API reference, no issue-triage evidence. Internal enablement must be built from a source read, so plan for one engineer to become the designated expert and document the entity/config surface as a deliverable, not a side effect.

Scaling No evidence of chunked or batched export, memory bounds, or rate-limit handling. Treat large-catalogue performance as unknown and unproven. If our target is 100k+ SKUs, that is a Phase 2 go/no-go criterion, and the fallback is a scheduled export of our own design rather than this module's path.

Failure modes Most likely failure is silent partial sync — some SKUs exported, some rejected, no observability. Others: credentials misconfiguration from undocumented config surface; migration collateral damage to existing tables; and abandonment, where a PHP or Yandex API bump leaves us stranded mid-quarter. Mitigate by keeping the integration behind an internal interface so the module is swappable, feature-flagging it, and writing reconciliation checks that compare our catalogue against what Yandex Market actually received.

Ramp-up Two to three weeks for a competent Symfony/Doctrine engineer to be productive, most of it spent reconstructing documentation. Onboarding is concentrated in one person by design — record that as a key-person risk. If the team is Laravel-first, add a Doctrine learning curve on top, and question whether the Yandex channel justifies it.