- How do I install smorken/roles in a Laravel application?
- The package is not published on Packagist, so you add a vcs repository entry for the Bitbucket URL in your composer.json and then require smorken/roles, which means Composer credentials must be configured in CI and on every developer machine. A mirrored fork on a private registry is usually the cleaner long-term option. After installing, publish the package config and run its migrations, and check the migration for collisions with any existing roles or role_user tables before migrating a database that already has one.
- Which Laravel and PHP versions does smorken/roles support?
- The repository does not publish version tags or a visible CI matrix, so there is no authoritative compatibility statement to point at. Read the composer.json constraints in the repository and treat them as a claim rather than proof. For anything beyond a prototype, pin the dependency to a specific commit and run your application's test suite against the exact Laravel and PHP versions you deploy.
- How do I assign roles to users with smorken/roles?
- You add the package's trait to your Eloquent user model, which gives the model the relationship and helper methods for roles. From there you attach one or more roles, either through the trait's helper methods or by writing to the role pivot table directly during seeding. Roles themselves are ordinary Eloquent records, so they can be created and managed from a seeder, an admin screen, or tinker.
- How do I check a user's roles in Blade templates or route middleware?
- The package provides helper methods on the user model plus route middleware and Blade-friendly conditionals, so a typical guard is middleware on a route group and a matching check in the view. Keep role strings consistent across controllers, middleware, and templates, because a typo is a silent failure that grants or denies the wrong thing. Add a feature test for at least one allow case and one deny case per guarded route.
- Does smorken/roles integrate with Laravel Gate and policies?
- It runs alongside Laravel's native Gate and policy system rather than building on it, so you end up with two places where authorization decisions are made. That is workable for a small application with a stable role set, but it invites drift once policies appear. If you adopt it, write down which layer owns which decision and review code against that rule.
- Is there a test suite, and how should I test the authorization myself?
- There is no visible test suite in the repository, so you cannot rely on upstream coverage of denial paths. Build your own feature tests around every guarded route and every role check, and make the deny case the priority, since a broken allow is loud and a broken deny is silent. Treat the package code as something your team owns and reviews rather than a vetted dependency.
- How does caching work and how do I invalidate it when roles change?
- The package has a configurable caching layer for role lookups, which is what makes repeated checks cheap in application code. The cache invalidation story on role change, especially under concurrent writes, is not documented, so verify it against your own code path before trusting it. If it does not clear automatically, flush the relevant cache keys whenever a role is attached, detached, or the pivot changes, and cover that behaviour with a test.
- Does smorken/roles support per-team or multi-tenant roles?
- Based on its documented surface, roles are global to the application, with no team or tenant scoping, no resource-level policy layer, no delegation, and no audit history. That makes it a reasonable fit for internal admin tooling, back-office dashboards, and single-tenant B2B tools with a small stable role set, but not for multi-tenant SaaS where roles are per organization. For those cases use a package or framework feature that models tenancy explicitly.
- What are the risks of depending on smorken/roles in production?
- The repository is a single-author Bitbucket project with no stars, no dependents, no visible tags, and no Packagist presence, so the realistic assumption is that there will never be an upstream fix. Because authorization is a security boundary, a broken deny path can grant access silently and go undetected for months. Mitigate by mirroring the code into a fork you control, naming an internal owner, pinning to a commit, and keeping a tested fallback to Laravel's native Gate if the repository disappears.
- What are the alternatives to smorken/roles?
- For a maintained community package, spatie/laravel-permission is the usual choice and covers teams plus a much larger feature surface. Laravel's own Gate and policy system handles most resource-level authorization without any extra dependency. If an external identity provider already issues authorization claims, use those rather than introducing a second source of truth.