Module Laravel Package

Product Decisions This Supports

• Modular feature packaging: panelis-php/module supports splitting a Laravel application into self-contained modules. The v1.4.0 change — registering permissions from within a module — lets each module declare its own access rules alongside its routes, migrations, and views. This is the enabling primitive for feature-flagged, entitlement-gated, or tiered releases without cross-team coordination in a shared authorization file.
• Build vs. buy for internal admin/panel tooling: If the roadmap includes an operator-facing admin panel or a multi-tenant SaaS back office, this package is a candidate to buy into rather than build a bespoke module registry and permission layer. Evaluate against the cost of a custom module loader plus spatie/laravel-permission wiring.
• Roadmap sequencing for RBAC: Permission self-registration inside modules suggests permission definitions ship with the feature that needs them. That supports a roadmap where authorization work is distributed across feature teams rather than centralized — a meaningful org-design decision, not just a technical one.
• Packaging and add-on strategy: If the product plan includes first-party or third-party add-ons/extensions, module-scoped permission registration is the mechanism that makes an add-on marketplace or partner-extension model governable. It directly informs whether "extensibility" is a credible roadmap pillar or a slideware one.
• Pricing/packaging decisions: Module-level permission registration is the technical hook for mapping plans → modules → permissions. It makes per-tier feature gating tractable and auditable.

Open product questions this release surfaces (to resolve with engineering): Does registration happen at boot, via a service provider contract, or a config manifest? Is it idempotent across module reloads? Does it integrate with an existing gate/policy or a third-party permission package, or does Panelis own the permission store? These determine whether the capability is production-grade for billing-critical entitlement checks.

When to Consider This Package

Consider it when:

• The application is Laravel and the team has already decided — or is seriously evaluating — a modular monolith rather than microservices.
• You need per-module authorization ownership: modules ship with their own permissions, and you want that co-located rather than in a central seeder.
• You are building an admin panel, back office, or multi-tenant SaaS where feature availability maps to permissions.
• The team is standardized on the Panelis ecosystem or is willing to adopt its conventions wholesale.
• You want to reduce time-to-first-module for a small team that cannot afford to design a module contract from scratch.

Look elsewhere when:

• Authorization is the only need. spatie/laravel-permission is more widely adopted, better documented, and has a larger hiring/troubleshooting pool. Adopting a module framework to get RBAC is over-buying.
• You need ecosystem maturity signals. This is a small, single-maintainer project at v1.4.0 with a one-line changelog for a feature release. If the product has a multi-year support horizon and no appetite for vendor risk, prefer a maintained alternative or in-house code.
• You require documented upgrade paths and deprecation policy. There is no evidence yet of a versioning contract, LTS commitment, or security disclosure process.
• You are on a microservice or event-driven architecture. Module registration is a monolith-shaped abstraction; the fit will be poor.
• Regulated/compliance-heavy contexts where you need SBOM, CVE tracking, and auditable dependency provenance — validate this first.

Adoption criteria before committing: confirm the permission-registration API is stable and documented; verify Laravel version support against your upgrade cadence; check test coverage and CI; confirm a bus-factor mitigation (forkability, license permissiveness); and pilot on one non-critical module before standardizing.

How to Pitch It (Stakeholders)

For executives — one paragraph: panelis-php/module is a Laravel package that lets us build the product as a set of self-contained modules, each carrying its own access rules. The v1.4.0 release is a small but directionally important step: modules can now register their own permissions, which is what lets us ship features and their access controls together, and later map modules cleanly to pricing tiers. It is a low-cost, reversible bet — MIT-style open source, adoptable on a single module first. The caveat is maturity: it is a young, single-maintainer project, so we should treat it as a productivity accelerator for internal structure rather than a load-bearing dependency for billing-critical authorization until engineering has validated the API and we have a fallback plan.

For engineering — the ask: Spike one module using v1.4.0's permission registration. Report back on: (1) the registration contract and whether it is idempotent; (2) whether it composes with spatie/laravel-permission or replaces it; (3) Laravel version support and test coverage; (4) effort to remove it if we change our minds. Timebox it; we greenlight broader adoption only if the module boundary stays clean and the permission layer is not a lock-in point.

Do not pitch it as: a replacement for a mature authorization library, a security boundary, or a committed long-term platform bet. It is an internal-architecture convenience with an emerging feature set.