Organizations Teams Laravel Package

Technical Evaluation

What the package is. liberusoftware/organizations-teams is a Laravel domain module covering the org/team lifecycle: teams, memberships (user↔team with roles), invitations (token issuance/acceptance), ownership, an "active context" switcher, and the scoping boundary that follows from that context. It is a business-domain package, not infrastructure — its value is the opinionated model and the boundary enforcement, not novel technology.

Architecture fit. The domain (multi-tenant or multi-workspace scoping) is one every SaaS eventually needs, so the fit is conceptually strong. The question is whose opinion. Based on the description, the package likely assumes a single-database, row-scoped tenancy model with a current_team_id-style pointer on the user and a resolution layer (middleware/helper) that sets request context. That fits a standard Laravel + Eloquent + session-auth stack cleanly. It does not fit if we need database-per-tenant isolation, if we already run Laravel Jetstream teams (table and concept collision), or if our authorization is centralized in spatie/laravel-permission and we don't want a second role model.

Integration feasibility. Mechanically straightforward: composer require, publish config and migrations, apply a trait/contract to the User model, register middleware, wrap routes. Call it 1–2 days to a working spike. The hard part is not installation, it is the current-context boundary — that boundary must hold in HTTP, queued jobs, scheduled commands, console, and any API surface. Most integrations of this shape fail there, not in composer.json.

Technical risk: high, and mostly supply-chain rather than code. The signals are unambiguous: 0 stars, 0 dependents, composite score ~20/100, and a single-vendor module family (liberusoftware/module-*) with no visible downstream usage. There is no community to validate the API, no issue history to read, and no third-party answer to any question we will have. The stated last release (2026-10-27) should be verified against Packagist — confirm it is a real semver tag with a changelog, not a metadata artifact or an unreleased branch. MIT licensing is fine and removes legal friction. Net: do not adopt as a direct production dependency. Either fork/vendor it as an internal starting point, or use it as a reference implementation and own the code. Opportunity score (~45) suggests the problem space is worth solving; it does not argue for this artifact.

Key questions before any code is written.

1. What are the composer.json constraints — Laravel 10/11/12, PHP 8.1+, and does it pull in sibling liberusoftware modules transitively?
2. Is tenancy single-DB row-scoped or connector-based? Is there a documented extension point for DB-per-tenant?
3. How is context propagated into queued jobs and console commands — explicit context object, or ambient global state?
4. Is scoping enforced by global scopes, repository queries, or policy checks only? Global scopes are the only variant that fails safe.
5. Test suite: coverage, presence of tests for cross-tenant leakage, invitation replay, ownership transfer races.
6. Does ownership support multiple owners, transfer, and orphan prevention (last-owner-leaves behavior)?
7. Role model: string enum, config-driven, or polymorphic? Can it delegate to an existing permission system?
8. How does the invitation token work — hashed at rest, single-use, expiry, rate limiting, email enumeration resistance?
9. Are migrations reversible and are table names prefixed/configurable (collision with an existing teams table)?
10. Who maintains it, and what is the stated versioning/BC policy?

Integration Approach

Stack fit. Target Laravel 10–12 with PHP 8.2+, Eloquent, and Sanctum for API tokens. The package should be UI-agnostic (Blade/Livewire/Inertia neutral), so the frontend choice is ours. Required adjacent decisions: (a) confirm the scoping column naming so it doesn't fight our conventions, (b) decide whether membership roles replace or wrap our existing authorization, (c) decide session vs. header-driven context for API clients.

Migration path. Greenfield is the clean case and where this package has real leverage — it saves a sprint of schema and invitation-flow design. Brownfield is materially harder: existing users/organizations/teams tables need mapping into its schema, memberships and ownership need backfill, and any table named teams must be reconciled. Plan a backfill script that derives memberships from existing FKs, assigns an owner per org explicitly (do not infer silently), and dual-writes the context pointer for one release before cutover.

Compatibility risks to check early. Jetstream team scaffolding (near-certain collision), spatie/laravel-permission (two role systems is a permanent tax), UUID vs. auto-increment key assumptions in its migrations, and whether it registers global scopes that would silently filter queries in unrelated packages.

Sequencing.

1. Source audit (0.5–1 day). Read migrations, models, middleware, and tests directly. This assessment is based on metadata, not code; the code review is the gate.
2. Isolation spike (1–2 days). Sandbox branch, full flow: create org → invite → accept → switch → verify a second user in a second org sees nothing of the first.
3. Boundary abstraction. Wrap it behind two internal interfaces — a context resolver and a membership/authorization facade — so the vendor is replaceable without touching call sites. This is the single highest-value hedge given the bus-factor risk.
4. Context enforcement. HTTP middleware, plus explicit propagation into every queued job and console command. Treat ambient context in jobs as a defect, not a convenience.
5. Security review. Invitations and ownership transfer are the two attack surfaces; review both before any external user touches them.
6. Rollout behind a feature flag, with a kill switch back to the prior model.

Operational Impact

Maintenance. Assume we become the maintainers. Pin an exact version (not a caret constraint), vendor or fork the source into our repo, and record the upstream commit SHA so we can diff future releases. Budget ongoing cost for Laravel major upgrades: an unmaintained package that touches the User model and registers global scopes is a recurring upgrade blocker, not a one-time install.

Support. Effectively zero external support. No community answers, no Stack Overflow corpus, no issue-tracker history to mine. Every question is answered by reading source or by our own team. This is acceptable for a well-bounded domain module, unacceptable for anything on the critical auth path without the abstraction layer described above.

Scaling. The hot paths are (a) resolving current context on every request, and (b) membership lookups for authorization. Required: composite indexes on membership keys (user_id, team_id and the reverse), a cached context resolution per request rather than repeated joins, and eager-loading of membership/role on the authenticated user. The invitations table grows monotonically — needs an expiry/cleanup job and an indexed token lookup. None of this is exotic; all of it is work the package may or may not have done for us.

Failure modes, ordered by severity.

• Context leakage across tenants. Highest severity by an order of magnitude. Any query path that bypasses the scope (raw query builder, withoutGlobalScopes, a job with no context, an Octane worker reusing stale state) becomes a cross-tenant data exposure. This is the failure that turns a package decision into an incident review.
• Stale context in long-lived workers. Octane and queue workers must reset context per job/request; ambient state that survives the boundary is a latent bug.
• Orphaned organizations. Last owner leaves, transfers fail, or a user is deleted without ownership reassignment. Needs an explicit invariant and a repair job.
• Ownership transfer races. Concurrent transfers or a transfer racing a member removal; needs transactional guards.
• Invitation abuse. Replay of accepted tokens, expired-token acceptance, user enumeration via invite response differences, and unique-constraint failures on re-inviting a soft-deleted member.
• Cascade deletes. Deleting a team or user silently dropping memberships that other records still reference.

Ramp-up. One to two developer-days for the source audit; roughly one sprint to integrate, harden the context boundary, and complete the security review for a team already fluent in Laravel. A team new to the domain should add a week for schema and authorization model decisions. Documentation quality is unknown and should be treated as absent in planning — the tests are the spec, which is another reason the audit is the gate.

Bottom line. The problem this package solves is real and worth solving; this specific artifact is unproven, has no adoption signal, and carries a real chance of becoming our maintenance burden. Adopt the design if the source audit is clean, adopt the code only as a fork behind an internal interface, and do not put it on the critical path as an unexamined Composer dependency.