Description
BaseContext in packages/server/src/entity/types.ts hardcodes auth and tenancy fields that every EntityContext and ServiceContext inherits:
export interface BaseContext {
readonly userId: string | null;
readonly tenantId: string | null;
readonly tenantLevel?: string | null;
authenticated(): boolean;
tenant(): boolean;
role(...roles: string[]): boolean;
}
These fields appear on every handler ctx parameter — even in apps that have no auth or tenancy configured. This is misleading: a developer sees ctx.tenantId in autocomplete and assumes multi-tenancy is active, when in reality it's always null.
Problem
- DX noise — simple apps see auth/tenancy properties they never configured
- Misleading —
ctx.role('admin') suggests role-based auth is available when it isn't
- Not inferrable — there's no generic parameter or configuration point to control what's on the context
Possible directions
- Make BaseContext generic — derive the shape from server/auth/tenancy configuration so only configured features appear on
ctx
- Split into mixins —
AuthContext, TenantContext etc. that get composed based on config
- Keep as-is but document — accept the nullable fields as a universal interface (simplest, least work)
Found during
Typed action I/O work (#2003) — noticed while reviewing hover types in a demo app with no auth configured.
Description
BaseContextinpackages/server/src/entity/types.tshardcodes auth and tenancy fields that everyEntityContextandServiceContextinherits:These fields appear on every handler
ctxparameter — even in apps that have no auth or tenancy configured. This is misleading: a developer seesctx.tenantIdin autocomplete and assumes multi-tenancy is active, when in reality it's alwaysnull.Problem
ctx.role('admin')suggests role-based auth is available when it isn'tPossible directions
ctxAuthContext,TenantContextetc. that get composed based on configFound during
Typed action I/O work (#2003) — noticed while reviewing hover types in a demo app with no auth configured.