Thanks to visit codestin.com
Credit goes to GitHub.com

Skip to content

Improve consistency and clarity of Blade directive naming #3

@sh-sabbir

Description

@sh-sabbir

Tyro currently provides several custom Blade directives for checking roles and privileges. While they work well functionally, the naming could be improved for consistency and clarity.

Current directives include:

  • usercan
  • hasanyprivilege
  • hasanyrole
  • hasprivilege
  • hasprivileges
  • hasrole
  • hasroles

There are two related concerns:

  1. Inconsistent naming convention
    The directives use mixed styles (all-lowercase, different verb forms), which makes the API slightly harder to scan and remember. In the Laravel ecosystem, custom Blade directives are commonly written in camelCase, which improves readability and aligns better with existing conventions.

  2. Ambiguous meaning for plural directives
    Directives such as hasroles and hasprivileges are not explicit about whether they check for any or all of the provided values. This ambiguity can lead to confusion and subtle authorization mistakes.

Proposed improvement
Adopt a consistent camelCase naming convention and make semantics explicit by using Any / All instead of relying on pluralization.

Example canonical directives:

  • @hasRole
  • @hasAnyRole
  • @hasAllRoles
  • @hasPrivilege
  • @hasAnyPrivilege
  • @hasAllPrivileges

Existing directive names can be retained as aliases for backward compatibility, while the new names are documented as the preferred approach.

Relation to Laravel’s built-in authorization directives
Laravel itself provides the @can, @cannot, and @canany Blade directives for authorization checks based on abilities, gates, and policies. These directives follow a clear, expressive naming pattern and serve as a good reference point for custom authorization-related directives. (Ref)

Aligning Tyro’s custom directives more closely with these conventions would make them feel more familiar to Laravel developers while keeping Tyro’s role/privilege abstractions intact.

If this direction is acceptable, I’m happy to submit a PR that introduces the new names, keeps the existing ones as aliases, and updates the documentation accordingly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions