Laravel Access Laravel Package

Technical Evaluation

Architecture fit

• laravel-access is a Laravel authorization package in the roles/permissions space; v0.1.10 adds dynamic permission definitions, meaning permission catalog entries can be introduced at runtime rather than being fully fixed at deploy time (config files, seeders, or enum-like constants).
• This is a meaningful architectural shift for consumers: the permission catalog becomes data rather than code. That fits multi-tenant products, admin-configurable RBAC, and modular/plugin architectures where modules register their own permissions on boot.
• It also moves the package closer to the Gate/Policy layer as a source of truth, which raises the question of whether it complements or competes with Laravel's native Gate::define / policies. A TPM should not treat this as a drop-in until that boundary is documented.

Integration feasibility

• Integration surface is likely small and idiomatic (service provider, migrations, a trait or middleware, Gate integration). Pre-1.0 Laravel packages of this shape are typically installable in under a day for a spike.
• The dynamic-definition feature implies at least one new storage/persistence path and a registration API. Both need to be reviewed against our existing seeding and deployment process before we commit.
• Feasibility is medium-high for a spike, medium for production — gated on the unanswered questions below.

Technical risk

• Pre-1.0 semver (highest risk). We are on 0.1.x. Under semver, 0.x minor bumps may contain breaking changes. A single feature release is not evidence of API stability, and the changelog gives no deprecation or migration notes.
• Cache coherence. Dynamic definitions almost always require invalidation of permission/role caches. Stale authorization caches are a security-adjacent failure mode, not just a performance one.
• Privilege escalation surface. If permission definitions are writable at runtime, the write path becomes a privileged operation. Who can define a permission, and is that audited?
• Source-of-truth drift. Two ways to declare permissions (static + dynamic) invites divergence between code, seeders, and the database across environments.
• Single-release evidence. One feature commit (#49) tells us nothing about test coverage, maintainer cadence, or downstream adoption.

Key questions

1. Where are dynamic permissions persisted, and is there a published migration/schema contract?
2. What is the registration API — boot-time only, or genuinely runtime? Is it idempotent across Octane/queue workers?
3. How is the authorization cache invalidated on definition change, and is that observable/measurable?
4. Does it layer on top of Laravel Gate/Policy, or replace them? Any conflict with existing policies?
5. Is multi-tenancy supported — per-tenant permission catalogs, or a single global namespace?
6. What Laravel and PHP versions are supported, and is there a stated 1.0 timeline or BC policy for 0.x?
7. Is there an audit trail for permission definition changes?
8. Test coverage, CI status, and open-issue count on the repo?

Integration Approach

Stack fit

• Assumed fit: standard Laravel app (PHP 8.x, Laravel 10/11/12) using built-in auth. Verify version constraints in composer.json before anything else.
• Fits well if we already use DB-backed roles. Fits poorly if we rely entirely on hand-written Gate::define calls and config-driven abilities, since dynamic definitions would introduce a second, competing registry.

Migration path

1. Read-only spike (1–2 days). Install in a scratch branch, reproduce the dynamic-definition flow from issue #49, and inspect the resulting schema and cache behavior.
2. Pin and isolate. Pin the exact version (0.1.10), no caret range, while pre-1.0. Wrap all package calls behind a thin internal AuthorizationService so a swap-out is a one-file change.
3. Backfill from current source of truth. Import existing roles/permissions from seeders or config into the package's store; reconcile counts and diff before enabling.
4. Enable dynamic definitions behind a flag. Only for non-privileged, admin-managed permission namespaces first.
5. Cut over enforcement (middleware / Gate::allows paths) once parity tests pass.

Compatibility

• Backward compatibility from 0.1.9 → 0.1.10 is likely additive, but this is an inference, not a guarantee. Changelog contains no "BREAKING CHANGE" footer, which is weak positive evidence only.
• Octane/queue-worker compatibility for runtime-defined permissions must be explicitly verified — long-lived workers hold state.

Sequencing

• Blocking prerequisites: schema review, cache-invalidation behavior confirmed, and a decision on whether the package owns authorization or defers to Laravel's Gate.
• Do the spike before committing to a design that removes our static permission config. Keep static definitions as the fallback path until 1.0.

Operational Impact

Maintenance

• Expect to track releases closely. At 0.1.x with visible feature velocity, pinning plus a monthly upgrade review is the realistic cadence.
• Vendor risk is real: single-maintainer-looking namespace, low release count, and no LTS signal. Budget for the possibility of forking or replacing.

Support

• Internal Tier-1 support burden is low (authorization failures surface as 403s). Tier-2 burden is moderate because dynamic permissions add a debugging dimension: "why does this user have this permission" now requires inspecting DB state, not just code.
• Recommend a small internal admin/diagnostic view over the permission catalog before go-live.

Scaling

• Permission checks run on nearly every request. Confirm whether resolution is cached and whether the cache is per-user, per-tenant, or global; a per-check DB query will not survive production traffic on hot paths.
• Dynamic definition writes should be rare and admin-scoped; if they are frequent, cache thrash is the expected bottleneck.
• Multi-tenant deployments multiply the catalog size — validate lookup strategy before landing in a shared-database multi-tenant app.

Failure modes

• Stale cache after a definition change → users retain revoked permissions. Highest severity.
• Drift between code-declared and DB-declared permissions across environments → "works in staging" authorization bugs.
• Package upgrade breaking the registration API mid-sprint (0.x semver).
• Unauthorized write access to the definition store → privilege escalation.
• Worker state divergence under Octane/queues.

Ramp-up

• Developer ramp-up: low, ~half a day for a Laravel-fluent engineer.
• Team ramp-up: 1–2 sprints to reach confidence, dominated by the cache-invalidation and source-of-truth questions rather than the API itself.
• TPM recommendation: adopt for a bounded spike, defer production commitment until the key questions are answered and the package reaches a stable API (or we accept and mitigate the 0.x risk with pinning and an abstraction layer).