@casl/vue: wrong 'do' prop check in can.ts

Describe the bug Cannot use I prop in Can component

To Reproduce

<Can I="read" a="Post"></Can>

It’s an example from docs

Expected behavior Can component should use I or do prop.

if I is undefined then use do prop

or if do is undefined then use I prop.

Let’s see can.ts Line 66

const $props = props as Record<string, any>;
let actionProp = 'do';
let subjectProp = 'on';

if (!(actionProp in props)) {
  actionProp = 'I';
  subjectProp = detectSubjectProp(props);
}

I checked props parameter in debugger. Even if when I use I property but props has a key of do with undefined value.

I think that condition should be like below

if ($props[actionProp] === undefined) {
  actionProp = 'I';
  subjectProp = detectSubjectProp(props);
}

and also detectSubjectProp too

function detectSubjectProp(props: Record<string, unknown>) {
  if (props['a'] !== undefined) {
    return 'a';
  }

  if (props['this'] !== undefined) {
    return 'this';
  }

  if (props['an'] !== undefined) {
    return 'an';
  }

  return '';
}

It works for me !

CASL Version @casl/ability - v6.3.1 @casl/vue - v2.2.0

Environment: Node: v16.17.0

[ahas]

I don’t understand what it means that you cannot use I prop? there is a test that ensures this is possible -> https://github.com/stalniy/casl/blob/master/packages/casl-vue/spec/can.spec.js#L8

You used in operator to check actionProp is do or I. Vue initializes component property do with undefined even if I used I property without do.

For example

<Can I="create" a="Post">...</Can>

Properties

{
  "I": "create",
  "do": undefined, // 'do' key exists. Vue always initializes with undefined value even if when you don't use 'do'.
  "a": "Post",
  // Skipped
}

so… actionProp is still do and props has a key of do and !(actionProp in props) equals false and $props[actionProp] is undefined then “Neither I nor do prop was passed in <Can>” error will be thrown.

I don’t understand why that test passed. I’m using nuxt3-rc.12 and actually not working.

[stalniy]

looks like from vue@3.1.x or vue@3.2.x the behavior was changed because it worked as expected in vue@3.0.x