smorken/roles
A Laravel package for role-based access control. Assign roles and permissions to users, guard routes with middleware, and check abilities in Blade or application code. Simple configuration and caching make authorization quick to set up and maintain.
Architecture fit. smorken/roles is a conventional Laravel add-on: a service provider, a publishable config, migrations, an Eloquent trait for the User model, and helpers for route middleware and Blade conditionals, with configurable models and a caching layer. That is a shape every Laravel team already knows, and it slots into a standard app with no external service, queue, or broker dependency. The TPM-relevant framing is that this covers the commodity layer of authorization — storing roles, attaching permissions to roles, and asking "does this user hold role X?" — and stops well short of a full authorization capability. There is no evident support for team/tenant-scoped roles, resource-level policies, delegation, or audit history. Plan the surrounding workstreams (policy design, audit requirements, admin UX) as still-unscheduled rather than assuming the package absorbs them.
Integration feasibility. The binding constraint is distribution, not code. This is a single-author Bitbucket repository with zero stars, zero dependents, and no Packagist presence, so consuming it means a vcs Composer entry requiring credentials in CI and on every developer machine — or, better, a mirrored fork on a private registry. That is roughly a day of platform work and is the same overhead as any internal package, but it is a coordination item: it lands on platform/DevEx, not on the feature team, and needs to be scheduled before the first consuming app can build. The code footprint is small enough that a competent Laravel engineer can read the entire public surface in an hour, which makes the evaluation cheap and the decision fast.
Technical risk. High relative to delivered value, and the risk is circumstantial rather than architectural.
Gate/policy system is the framework-native path. A parallel role helper invites drift where some checks route through the package and others through policies, and reviewers can no longer answer "where is authorization enforced?" without reading the whole codebase.Key questions. (1) Which Laravel and PHP versions are supported, and is there a CI matrix? (2) Is there a test suite covering denial cases, or only happy paths? (3) Does it interop with Gate/policies, or sit orthogonally? (4) What is the cache invalidation story on role change, especially under concurrent writes? (5) Is the license compatible with our client-delivery and distribution model? (6) What is our contingency if the author deletes the repository — do we have a fork and a named internal owner? (7) Are roles global only, or is per-team scoping possible? (8) Does the migration collide with any existing roles/role_user schema in the portfolio?
Stack fit. Appropriate for Laravel applications that currently have no authorization layer or only ad-hoc is_admin booleans — internal admin tooling, back-office dashboards, MVPs, single-tenant B2B tools with a small, stable role set. Not appropriate where spatie/laravel-permission, Laravel policies, or an external IdP already issues authorization claims; adding this creates a second source of truth for the same question and guarantees inconsistency. Not appropriate for multi-tenant SaaS with per-organization roles, or anywhere "permission" is a customer-facing feature.
Migration path. Treat this as fork-and-own, not as a dependency we consume. Concretely: mirror the repository into our own namespace and tag 1.0.0-internal at current HEAD; publish via a private registry (Satis, Private Packagist, or a monorepo path repository) rather than per-project vcs entries; write a characterization suite over the public surface (assign, remove, positive check, negative check, middleware allow, middleware deny) before touching anything; and place a thin internal AuthorizationService interface in front of it so call sites never reference the package directly. That last step is the one that protects the roadmap — it converts a dependency decision into a reversible implementation detail.
Compatibility. Validate against our actual pinned matrix rather than the README: clean install, non-colliding migrations, no trait conflicts on the User model with existing traits. If the portfolio spans multiple Laravel majors, assume a compatibility shim and budget it. Confirm behavior under Laravel's native authorization middleware stack, since that is where a silent bypass would appear.
Sequencing. Run this as a four-gate program, not a single adoption decision.
The honest baseline at every gate is that a roles trait is on the order of a day of engineering. Adoption buys us that day; it costs us a dependency we did not choose. Keep that arithmetic visible in the gate reviews so the decision stays proportionate.
Maintenance. Low but non-zero and, critically, unshared. There is no upstream maintainer to absorb Laravel major-version bumps or PHP runtime upgrades, so "upgrade" means we do it. Budget 2–4 engineer-days per year in steady state, concentrated at framework upgrade windows and multiplied by the number of consuming applications if we do not centralize ownership. The cost is not code volume — it is the standing obligation to notice.
Support. No vendor, no SLA, no escalatable issue tracker. Support is entirely internal, which makes the named-owner assignment a hard prerequisite rather than a nicety. An unowned authorization dependency is a standing audit and security-review finding, and it will surface at the worst possible moment — during an incident or a compliance review, not during sprint planning.
Scaling. Technically fine: role checks are cached lookups and add negligible request-path load at our volumes. The scaling ceiling is organizational and data-model shaped. As applications multiply and role granularity increases, a global-role model degrades into role explosion, then into ad-hoc per-resource checks bolted around the package, and finally into a replacement project. For the TPM this means: define the exit criteria at adoption time — the number of roles, the first per-team requirement, the first audit request — and treat any of them firing as a trigger to re-plan rather than to extend.
Failure modes. Maintain a small risk register with owners and mitigations:
composer.lock, mirrored fork.Ramp-up. Low for engineers: the public surface is small enough to learn from the README in under an hour, and the wrapper interface means most engineers never touch the package at all. The ramp-up cost that actually matters sits on the operations and support side — on-call needs to know this exists, who owns it, what a role-check failure looks like in logs, and how to revoke access during an incident. Budget a short runbook and a named-owner handoff as part of the integration, not as a follow-up. Finally, keep the stakeholder framing explicit: this is temporary scaffolding that lets role-gated features move earlier on the roadmap at a measured cost of days, not a platform bet — and it must not be allowed to shape how we model customers, teams, or permissions, because that is precisely the part it cannot carry.
How can I help you explore Laravel packages today?