Bug: TypeScript Compilation Error Due to Strict MergeUnion<T> Definition in @casl/ability

[maltyxx]

Bug Description

The MergeUnion<T> type in @casl/ability is overly restrictive, causing TypeScript errors when using dot-notation paths (e.g., 'tenant.id') in conditions. This limitation prevents referencing nested properties as string keys, even though CASL and MongoDB support such syntax.

Steps to Reproduce

1. Configure an ability:

   import { AbilityBuilder, Ability } from '@casl/ability';
   
   const { can, build } = new AbilityBuilder(Ability);
   can('read', 'User', { 'tenant.id': '12345' }); // Dot-notation for nested property
   const ability = build();

2. Check permissions:

   ability.can('read', 'User', userData);

3. TypeScript raises an error:

   TS2345: Argument of type `{ 'tenant.id': string }` is not assignable...
   

Expected Behavior
TypeScript should allow dot-notation paths without requiring type casting.

Proposed Fix
Modify MergeUnion<T> in conditions.ts to support arbitrary string keys:

type MergeUnion<T, Keys extends keyof T = keyof T> = {
  [K in Keys]: T[K];
} & {
  [key: string]: any;
};

This change aligns TypeScript behavior with CASL’s runtime capabilities, improving developer experience while maintaining backward compatibility.

Environment

• @casl/ability: v6.7.4
• TypeScript: v5.1.3
• Node.js: v20.18.1

[stalniy]

This change will basically allow any stringed property to be specified in conditions. Which is not good for the case when there are properly configured types.

I’ll double check this but I had the impression that TS will infer it by default from this mapping type

[maltyxx]

Thank you for your response! I understand your concern regarding type safety and the risks of allowing arbitrary string keys.

However, I find it unfortunate that CASL does not currently support conditions with nested objects like:

can('read', 'User', { tenant: { id: '12345' } });

This would align better with how many ORMs and libraries handle object relationships. For example, in an ORM, we often work with nested objects to represent relationships between entities, making this approach more natural and easier to use.

Supporting nested object conditions directly in CASL would improve both usability and consistency with ORM practices. It could also help avoid relying on dot-notation strings, which are less intuitive and more error-prone.

If implementing this behavior is not feasible for now, I'd appreciate any guidance on how to structure conditions more effectively within the current limitations.

Thanks again for your efforts on this library—it’s an amazing tool for access control. 😊

[matejchalk]

As a workaround for this issue, I'm using the following type in place of MongoQuery<T>:

import type { MongoQuery, MongoQueryFieldOperators } from '@casl/ability';
import type { Join, NestedPaths, PropertyType } from 'mongodb';

type CaslQuery<T> = {
  [Property in Join<NestedPaths<T, []>, '.'>]?:
    | PropertyType<T, Property>
    | MongoQueryFieldOperators<PropertyType<T, Property>>;
};

I basically took the Filter<T> type from mongodb and modified it to according to CASL's restrictions (e.g. no top-level operators like $or).

This provides type-safety for dot-notation paths, but requires the CaslQuery<T> to be casted as MongoQuery<T>.

[stalniy]

@maltyxx casl just uses MongoDb query by default. In mongodb nested objects (if they don’t include operators) are compared by exact equality, including the order of fields which is not usable in real life. They don’t even recommend to use this type of query.

That’s why casl don’t even support it.

Since, typescript supports literal types for a long time, it’s time to integrate @matejchalk approach into library. But I don’t have ETA for this