- Can I install ruwork/synchronizer-bundle in a Laravel application?
- No. It is a Symfony bundle built on Bundle classes, DI extension config trees, compiler passes, and the Symfony EventDispatcher, none of which Laravel consumes. There is no service provider, facade, or publishable Laravel config. Dropping it into a Laravel app is a port, not a composer require.
- What does ruwork/synchronizer-bundle actually do?
- It integrates Ruwork Synchronizer into Symfony to import and update Doctrine entities from external data sources. You define configurable synchronizers and processors, then run them through console commands. It is essentially an ETL-style bridge between an external source and Doctrine persistence.
- Is ruwork/synchronizer-bundle still maintained?
- No. The repository is archived, the last release was 2018-07-22, and it has zero stars and zero dependents. Upstream has explicitly disclaimed maintenance. Treat it as prior art rather than a maintained dependency.
- Does ruwork/synchronizer-bundle support PHP 8 and modern Laravel or Symfony versions?
- Unlikely without work. The package predates PHP 7.4 typed properties and has had roughly seven years without releases, so expect untyped signatures and possibly deprecated dynamic properties on PHP 8.2+. It was never tested against Laravel, and Symfony compatibility is limited to the era it was built for.
- How do I install and configure ruwork/synchronizer-bundle in Symfony?
- In Symfony you would composer require ruwork/synchronizer-bundle, register the bundle in your kernel, and configure it through the bundle's DI extension. Because the repository is a read-only subtree split, also check the upstream Ruvents repository for issues and history. There is no Laravel installation path.
- What are synchronizers, processors, and console commands in this bundle?
- Synchronizers orchestrate the flow from an external data source into Doctrine entities. Processors transform or map the incoming records before persistence. Console commands provide the CLI entry points that run the configured synchronizers.
- Can I extract the core logic from ruwork/synchronizer-bundle and rewrite it for Laravel?
- Possibly, but only after a timeboxed source audit. Map each class against Symfony and Doctrine imports and estimate the portable core versus framework glue. If the genuinely portable synchronization logic is only a few hundred lines, build it in-house on Laravel primitives and cite this package as prior art; if the core encodes non-obvious reconciliation semantics, a fork may be justified.
- Does ruwork/synchronizer-bundle handle idempotency, conflict resolution, and partial failures?
- The README-level description does not establish this, so you must audit the source. It is unclear whether idempotency, conflict resolution, and partial-failure handling live in the core or are delegated to callers. Given zero dependents, there is no production hardening evidence to rely on.
- What Laravel-native alternatives should I use instead of ruwork/synchronizer-bundle?
- For most Laravel apps, a combination of queued jobs, Illuminate Pipeline, and database upserts covers the same import-and-update ground. You can add source-specific readers or spreadsheet packages where needed. This avoids porting Symfony wiring and keeps the code on maintained Laravel primitives.
- Can I fork ruwork/synchronizer-bundle, and what license is it under?
- Yes, legally. It is MIT licensed, so forking and modifying is clean. Practically, you would vendor the repo read-only, strip the Symfony bundle wiring, and re-host the portable core under your own namespace as an internal Composer package.