Weave Code
Synchronizer Laravel Package
ruwork/synchronizer
A Laravel package that simplifies synchronizing related Eloquent models and their pivot data, letting you keep associated records consistent through a single declarative call instead of manual attach, detach, and update logic.
ruwork/synchronizer is a lightweight PHP utility for keeping related collections of objects in sync. It compares a current set of items against a desired one, then produces the operations—add, update, or remove—needed to reconcile them, so you can persist changes without hand-written diff logic.
It is framework-agnostic and fits naturally into Doctrine or Laravel entity relationships, form handling, and import workflows where incoming data must be merged into existing records.
- Diff-based reconciliation of existing vs. incoming items
- Emits add, update, and remove operations
- Works with arbitrary object collections
- Predictable, testable synchronization logic
- No framework dependency—integrates via simple callbacks
Frequently asked questions about Synchronizer
- What is ruwork/synchronizer used for?
- It is a small, single-purpose package from the RuWork family that provides synchronization primitives: it computes the difference between a desired collection and the current collection of related records, then applies inserts, updates, and deletes so the two stay consistent. Typical use cases are tags, pivot rows, permission sets, and price lists. Note that this repository is a read-only subtree split of ruvents/ruwork-synchronizer, so the code is published from the main monorepo.
- Which PHP and Laravel versions does ruwork/synchronizer support?
- The last release was on 2018-07-20, which places it in the PHP 7.1/7.2 and Laravel 5.5 to 5.8 era. Expect the composer.json platform constraints to hard-conflict with PHP 8.x and Laravel 9 and above. Check the exact php and illuminate/* requirements before planning any integration.
- How do I install ruwork/synchronizer?
- Require it with Composer from Packagist; the package is MIT licensed and PSR-4 autoloaded, so installation itself is standard. On a modern stack the install will likely fail on platform constraints, and using --ignore-platform-reqs is not an acceptable production posture. Forking with widened constraints or a path repository override are the realistic options.
- Is ruwork/synchronizer compatible with Laravel 10 or Laravel 11?
- Not as published. The 2018 release predates those versions by years and its Composer constraints almost certainly exclude PHP 8.2+ and current illuminate/* releases. You would need to fork the package, widen the constraints, and add a test suite that passes on your target PHP version.
- Does ruwork/synchronizer work with Eloquent models or is it framework-agnostic?
- The intended design is to decouple the diff and apply algorithm from Eloquent behind interfaces, so it can work with plain collections or custom repositories. Verify in the source whether the synchronizer is genuinely generic over collections or still couples to Eloquent or Doctrine models. It is a pattern library rather than an infrastructure library.
- Does ruwork/synchronizer wrap the sync in a transaction or support a dry run?
- This is undocumented. The key questions to answer by reading the source are whether the apply phase runs inside a transaction and whether a dry-run or plan mode is exposed. If neither exists, wrap the call in DB::transaction yourself and build a plan step before applying changes.
- Is ruwork/synchronizer safe to use in production?
- Treat it as unaudited third-party source. It has zero stars, zero dependents, a single release, and no activity for seven years, so there is no issue history, security disclosure channel, or CI signal to rely on. The codebase is small enough to read end-to-end in under an hour, which is the right way to de-risk it.
- How does ruwork/synchronizer compare to Laravel's sync() and upsert()?
- Laravel's native sync(), syncWithoutDetaching(), and upsert() already cover the majority of the pivot and collection reconciliation case. The package's value is the abstraction, a reusable diff and apply contract, which is cheap to reproduce as a first-party action class. For most applications a small app/Support/Synchronizer with tests is a better trade than the dependency.
- Does ruwork/synchronizer have a test suite that runs on PHP 8.2?
- Unknown from the published metadata, and there is no CI signal in the read-only subtree split. If you fork or vendor it, add a test suite that passes on PHP 8.2 and covers the edge cases. Specifically test empty desired set versus no-change semantics, ID type coercion breaking equality in the diff, and ordering assumptions.
- Should I fork ruwork/synchronizer or reimplement it?
- Reimplementing as a first-party action class is the preferred option: read the source, extract the diff and apply contract, and write it in app/Support/Synchronizer with tests. Fork and vendor only if the package encodes non-trivial semantics worth preserving, then widen platform constraints, add tests, and register it as an internal Composer package with an explicit owner. A direct dependency is only defensible on a legacy PHP 7.1 to 7.4 and Laravel 5.x stack with a time-boxed sunset.
Weaver
How can I help you explore Laravel packages today?