feat(member-base-nestjs-module): let applications name the casbin policy table

[luca-tw]

Why

Casbin policies went into typeorm-adapter's own casbin_rule and nowhere else. newAdapter accepts a second argument carrying customCasbinRuleEntity, but the module only ever passed the first one, so the table name was not reachable through MemberBaseModule.forRoot.

Two applications pointed at the same database therefore shared one policy table. Since the usual startup routine is "load the authoritative rules, clear the table, write them back", each one's boot briefly empties the table the other is enforcing against. Converging at the end is not the same as being isolated in between.

What

A new casbinRuleEntity option. Subclass typeorm-adapter's CasbinRule, name the table, hand it over:

@Entity('backend_casbin_rule')
export class BackendCasbinRule extends CasbinRule {}

MemberBaseModule.forRoot({
  casbinAdapterOptions: { type: 'postgres' /* ... */ },
  casbinRuleEntity: BackendCasbinRule,
});

Two decisions worth flagging for review

The config is undefined when the option is unset, not {}. newAdapter is then called exactly as it was before this option existed, so no existing deployment changes behaviour or leaves casbin_rule. The spec covers all three unset shapes (no options, {}, adapter configured but no entity).

Building that config is a standalone function rather than an inline ternary. The CASBIN_ENFORCER provider around it cannot be unit tested — it dynamic-imports typeorm-adapter (which jest.mock cannot intercept under ESM) and then opens a real connection, and option-providers.ts is excluded from coverage for that reason. Extracting it is what gives the new option test coverage at all. This is the same split, for the same reason, as load-typeorm-adapter.ts.

TypeORMAdapterConfig is restated locally because typeorm-adapter declares it but does not re-export it from its entry point; the alternative was a deep import of typeorm-adapter/lib/adapter.

Scope

This separates the cache, not the permissions. If both applications rebuild their policies from the same upstream tables, both still end up with identical contents, and a permission missing upstream stays missing in both. Setting the option on an application that already has policies starts it from an empty table — it does not migrate rows. Both caveats are stated in the README section.

Verification

• New spec: 5 passing.
• Package suite: 742 passed / 3 suites failing. Those 3 failures are pre-existing — verified by running the same suite on a clean tree at this commit's parent (737 passed, same 3 failures). All three come from ldapts, an optional peer dependency that is not installed in this checkout; tsc reports the same single unrelated error on the clean tree.
• ESLint clean on the changed files; the commit also passed the repo's lint-staged typecheck/lint/format hooks.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying utils-docs with    Cloudflare Pages

Latest commit:	4eaff8e
Status:	🚫  Build failed.

View logs

[cloudflare-workers-and-pages]

Deploying rytass-utils-storybook with    Cloudflare Pages

Latest commit:	4eaff8e
Status:	✅  Deploy successful!
Preview URL:	https://8051c1eb.rytass-utils-storybook.pages.dev
Branch Preview URL:	https://feat-casbin-rule-entity.rytass-utils-storybook.pages.dev

View logs