- Is baks-dev/four-tochki-orders a Laravel package?
- No. Despite being described as a PHP package, the install path is unambiguously Symfony: php bin/console baks:assets:install, Doctrine migrations, and PHPUnit groups run through a bundle-based console kernel. It is a module of BaksDev, a Symfony B2B/CMS distribution, not a Laravel package. Laravel has no bundle system and no bin/console, so it will not drop into a Laravel app unchanged.
- How do I install baks-dev/four-tochki-orders?
- Run composer require baks-dev/four-tochki-orders, then publish configuration and file assets with php bin/console baks:assets:install. After that, generate and apply the Doctrine schema changes with php bin/console doctrine:migrations:diff followed by doctrine:migrations:migrate. All three steps assume a Symfony application with the BaksDev bundle registered.
- What PHP version does baks-dev/four-tochki-orders require?
- The README badge specifies a minimum of PHP 8.4. That is a hard floor for a fairly narrow module, so installing it will force a runtime upgrade if your platform is still on 8.2 or 8.3. If you cannot upgrade, you would need to fork and relax the constraint, which then puts the maintenance burden on you.
- What does this package actually do, orders or products?
- The artifacts conflict: the package name says orders, the Composer description says products module, and the README says orders module. Public materials do not clearly define the bounded context. Resolve that scope question before estimating any integration work, because the answer changes the schema and the integration surface.
- Can I use baks-dev/four-tochki-orders in a Laravel application with Eloquent?
- Not directly. The package ships Doctrine entities and a Symfony asset and config pipeline, so a Laravel app would need either a Symfony bridge shim, a second ORM running alongside Eloquent, or a fork. Bridge approaches introduce a permanent two-frameworks-in-one-process cost that every future developer pays. Most Laravel teams are better off reading the entity and migration files as a domain model and re-implementing them as Eloquent models and Laravel migrations.
- Will the Doctrine migrations collide with my existing database schema?
- They can, and that is a real data-integrity risk during rollout. The package ships its own Doctrine schema for order and product entities, so running doctrine:migrations:diff in a database that is not managed by the same entity manager can produce destructive or conflicting DDL. Review the generated migration SQL line by line before running migrate, and take a backup first.
- How do I run the tests for baks-dev/four-tochki-orders?
- The README documents php bin/phpunit --group=four-tochki-orders. That is a group name, not evidence of coverage; no public test report or coverage figure is published. Treat the test suite as unverified and plan your own regression tests around whatever integration you build on top of it.
- Is baks-dev/four-tochki-orders actively maintained and safe for production?
- Treat abandonment as the base case. It has a single author, zero stars and zero dependents, and the release notes for recent versions are literally just the version string, so release metadata is not a quality signal. The MIT license means you can fork, and a fork-and-own posture is the only durable option for production use.
- Does the package document the 4tochki API, webhooks, or rate limits?
- No. Public materials contain no documented API client contract, no webhook specification, no error taxonomy, and no statement of whether order state is push- or poll-driven. Authentication model, rate limits, idempotency keys, and webhook signature schemes are all undocumented. Budget discovery time with the 4tochki side before committing to a delivery date.
- What are the alternatives to installing baks-dev/four-tochki-orders?
- The strongest alternative is to consume it as a reference implementation rather than a dependency: extract the Doctrine entity definitions and migration files as the closest available written 4tochki domain model, then rebuild them as Laravel migrations plus a service class and queued jobs. That keeps you in control and avoids a long-term dependency on a low-traction vendor. If your platform is already Symfony with Doctrine and a funded CIS roadmap, installing the bundle directly is the only scenario where the return is clean.