Organizations Teams Livewire Laravel Package

Getting Started

Install and confirm the dependency chain first. This package is a presentation adapter — it does not own the domain. Expect its composer.json to require a sibling domain package (something in the liberusoftware/organizations-teams-* family) plus livewire/livewire. Before writing any code, run:

composer require liberusoftware/organizations-teams-livewire
composer show liberusoftware/organizations-teams-livewire

Read the require block. You need to know which domain package supplies the Eloquent models and which Livewire major version is pinned, because both dictate everything downstream.

Where to look first, in this order:

1. vendor/liberusoftware/organizations-teams-livewire/composer.json — dependency constraints and autoload PSR-4 root (usually Liberu\Organizations\Teams\Livewire\).
2. The service provider(s) in src/ — look for Livewire::component(...) registrations, loadViewsFrom, loadRoutesFrom, and any mergeConfigFrom. This one file tells you 80% of how the package expects to be used.
3. resources/views/ — the Blade files reveal the expected props, the layout assumptions, and whether the components are full-page or inline.
4. README.md and any docs/ — with zero stars and zero dependents, the README is likely the only usage contract that exists; treat it as authoritative but verify against source.

First use case: a team management panel inside an existing dashboard. The realistic day-one goal is not to build an org system from scratch — it is to drop an org switcher and a team CRUD surface into an app that already has users and auth. Render the package's component in a Blade view:

<livewire:organizations.teams.index />

If Livewire::component() registrations use a different alias (e.g. teams.index, organizations.teams.list), grep the provider rather than guessing:

grep -rn "Livewire::component" vendor/liberusoftware/organizations-teams-livewire/src

Get one component rendering against real data before touching configuration. If it renders, the adapter's contract with the domain package is satisfied and you have a working baseline to extend.

Implementation Patterns

Treat the package as a view layer, not a feature. The healthiest integration is: your app owns routing, middleware, layout, and tenancy; the package owns the Livewire components and their Blade. Mount components inside your authenticated routes rather than enabling any package-provided route file, so you keep control of authorization and URL structure:

Route::middleware(['auth', 'verified'])->prefix('settings')->group(function () {
    Route::get('/teams', TeamSettings::class)->name('settings.teams');
});

Compose, don't fork. Wrap the package components in thin app-level Livewire components or Blade partials that add your chrome (navigation, breadcrumbs, flash messaging). When the package updates, wrappers survive; copied views do not.

Use events for cross-component coordination. An org switcher and a team list are naturally decoupled. If the package emits events (check $this->dispatch(...) / $this->emit(...) in src/), listen from your own components and persist the active organization in session or a scoped container binding. If it does not emit anything, add the dispatch by extending the component rather than patching vendor code:

class TeamIndex extends \Liberu\Organizations\Teams\Livewire\TeamIndex
{
    public function switchOrganization(int $id): void
    {
        parent::switchOrganization($id);
        $this->dispatch('organization-switched', id: $id);
    }
}

Then register your subclass under the same alias in a service provider that runs after the package's — order matters, and this is the cleanest extension point the package exposes.

Drive authorization through policies on the domain models. The adapter almost certainly calls $this->authorize(...) or relies on Gate. Register policies for the Organization and Team models in your AuthServiceProvider and let the package's components inherit them. Never rely on the package's built-in checks alone — with an unasserted license and no dependents, assume the guards are minimal.

Multi-tenancy: scope at the query level, not the component level. If you use a tenancy package, ensure your global scopes apply to the models the adapter queries. Because the adapter holds no tenancy opinion, a missing scope silently shows another tenant's teams. Write one feature test per component that asserts a user from tenant B cannot see tenant A's rows.

Testing pattern. Livewire components are cheap to test — do it, because you have no upstream test signal to lean on:

Livewire::actingAs($user)
    ->test(\Liberu\Organizations\Teams\Livewire\TeamIndex::class)
    ->assertOk()
    ->assertSee($team->name)
    ->call('delete', $team->id)
    ->assertHasNoErrors();

Snapshot the component list into your own test suite early; it becomes your regression net for package upgrades.

Gotchas and Tips

License is NOASSERTION — resolve this before production. This is not "probably MIT." Open vendor/liberusoftware/organizations-teams-livewire/LICENSE and confirm. If no license file ships or the terms are unclear, treat the package as all-rights-reserved and either get clarification upstream or plan to reimplement the views yourself. This is the single highest-risk item here and it is a legal question, not a technical one.

Zero stars, zero dependents, no issue history. You are the first integrator in any meaningful sense. Budget for reading source instead of documentation, and pin the exact version in composer.json ("liberusoftware/organizations-teams-livewire": "1.x-dev#<sha>" or a caret on a specific tag) rather than floating. Also note the release date metadata (2026-10-26) is anomalous — future-dated tags usually indicate automated or mis-set CI tagging. Inspect the tag history before trusting semantic versioning.

Livewire 2 vs 3 is a hard break. emit/dispatchBrowserEvent vs dispatch, $listeners vs #[On], and pagination view namespaces all changed. Verify which one the pinned constraint targets; a mismatch produces silent no-ops (events that fire into the void) rather than exceptions, which is a miserable debugging experience.

Published views shadow package updates permanently. php artisan vendor:publish --tag=...-views is tempting and then becomes a maintenance liability. Publish only if you must restyle, and record the publish in your upgrade notes. Prefer overriding individual Blade files via View::prependLocation() or a custom view namespace.

Component alias collisions. If the provider registers short aliases like teams.index, you can collide with your own components. Grep for existing Livewire::component calls in your app before enabling the provider's registrations.

Debugging blank components. A component that renders nothing is usually one of three things: a missing domain migration (tables absent — run php artisan migrate after checking the sibling package's migrations are loaded), a policy returning false and the view bailing early, or an unregistered component alias. Isolate with Livewire::test(...) in tinker rather than clicking through the browser.

Check loadMigrationsFrom and publish tags. If the domain package ships migrations, you need them published or loaded. Most silent failures at install time are missing tables, and the adapter will not tell you — you'll get an empty list and no error.

Extension points to prefer, ranked: (1) subclassing components and re-registering aliases, (2) policies and gates on domain models, (3) event listeners, (4) published config, (5) published views. Never edit vendor/. If the package offers none of 1–3 cleanly, fork it into your own namespace with attribution — with this adoption profile you are effectively the maintainer anyway.

Instrument the upgrade path now. Because there is no community to surface breaking changes, add a single integration test per mounted component and run it on every composer update. Treat green tests as your only changelog.