Avoid typescript warning when no roles key is supplied

[Philzen]

Line 108 indicates that this method can be used without supplying roles at all:

redwood/packages/cli/src/commands/setup/auth/templates/dbAuth.auth.ts.template

Line 108 in 4707b98

if (roles && !hasRole(roles)) {

However, this would trigger a typescript warning:

Argument of type '{}' is not assignable to parameter of type '{ roles: AllowedRoles; }'.
  Property 'roles' is missing in type '{}' but required in type '{ roles: AllowedRoles; }'.ts(2345)
auth.ts(101, 42): 'roles' is declared here.

This fixes it.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 4707b98. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 14 targets

• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run build
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build

---

Sent with 💌 from NxCloud.

[netlify]

✅ Deploy Preview for redwoodjs-docs canceled.

Name	Link
🔨 Latest commit	4707b98
🔍 Latest deploy log	https://app.netlify.com/sites/redwoodjs-docs/deploys/62e19cad00746100075b7076

[Philzen]

BTW – Currently, the method throws when called without any argument, so one always has to supply {} and cannot pass the method around without this as a pre-bound parameter.

Hence, my suggestion / wish for v3.0 would be to change this method from destructuring to simply use a discrete argument.

The hasRole-method signature was actually changed exactly that way in 84460eb, so it would only make sense to harmonize these APIs.

Would love to hear the core-team's thoughts on this.

[simoncrypta]

Thanks for this fix, that make sense!

[simoncrypta]

@Philzen For your suggestion, maybe @cannikin had some thought on it ?

[Philzen]

@Philzen For your suggestion, maybe @cannikin had some thought on it ?

@simoncrypta Actually #6110 fixed the limitation i described, which is awesome, now we can simply pass requireAuth to validateWith in our service methods!

Now there's really no big gain in changing the method signature of requireAuth, other than having harmonized method signatures of course. Though it is still interesting to learn why hasRoles signature was changed to the favorable, simpler version in 84460eb, but requireAuth was not.