- How do I install madbox-99/laravel-user-team-sync in a Laravel app?
- Install it with Composer using composer require madbox-99/laravel-user-team-sync. Laravel package auto-discovery registers the service provider, so you normally do not need to add it manually to config/app.php. After installing, publish the config file and migrations, review them, and run php artisan migrate.
- What Laravel and PHP versions does laravel-user-team-sync require?
- The package targets Laravel applications on PHP 8.1+ with Composer 2 and standard package auto-discovery. Before committing, check its illuminate/* constraints against your framework version, because that mismatch is the most common reason a simple package install fails. The minimum supported Laravel version for v1.7.0 is not clearly documented in the release notes, so verify it in composer.json.
- What exactly does laravel-user-team-sync sync between users and teams?
- It models the user-to-team relationship and keeps team memberships, user records, and assignments aligned automatically. Sync rules are configurable, so you can adapt how membership state is reconciled. It is aimed at cases such as integrating an external team source or keeping access consistent across Eloquent models.
- Do I need to publish the config file and migrations?
- Yes. The package ships publishable configuration and publishable migrations, and you should publish both before relying on it. Review the config defaults and the migration schema against your existing users, teams, and membership data, then run the migrations on a staging or production-shaped database first.
- Can team syncing run on a queue in the background?
- Yes, the package is described as queue-friendly, so sync work can be dispatched to workers rather than run inline in a request. Check the published config for queue-related options and make sure your jobs are idempotent, since membership sync may be retried. Test queue behavior with a realistic data volume before enabling it in production.
- Will it work with my existing User and Team models and membership data?
- It fits best when your models are named User and Team and membership is a simple pivot table with an optional role. If membership is polymorphic, supports nested teams, has multiple member types, or carries significant business logic, you will be fighting the package's assumptions and should treat it as a reference implementation. In either case, budget most of the effort for backfilling existing membership records and writing a rollback path.
- What changed in v1.7.0, and is it safe to upgrade?
- The v1.7.0 release notes contain only a compare link, so the actual changes are not documented in the release. Review the commit diff for new migrations, renamed config keys, trait changes, or deprecations before upgrading. Pin the dependency to an explicit version such as ^1.7 and test the upgrade on a throwaway branch rather than trusting the minor bump blindly.
- Are the package migrations reversible, or do they alter existing tables?
- Pivot-table migrations like these are typically not cleanly reversible once membership data has landed in them, so confirm what the published migrations create and whether they modify existing tables. Run them against a production-shaped schema clone and inspect the resulting tables before touching real data. Keep a backup and a rollback script that can restore your original membership records.
- Does laravel-user-team-sync handle roles and permissions?
- The package focuses on keeping user and team membership in sync, and membership may include an optional role field on the pivot. It does not appear to own full role or permission semantics, so expect authorization to remain in your application's existing layer. Verify this in the code before depending on it for access control.
- Is laravel-user-team-sync actively maintained, and what are the alternatives?
- It is a single-maintainer package, which means bus factor of one, no clearly documented security disclosure policy, and limited visibility into release cadence. If that risk is unacceptable, the alternatives are writing a small custom sync job or manually maintaining the user-team pivot yourself. Permission-focused packages are not direct substitutes because this package solves membership sync, not authorization.