Typed `to` Arguments

[skorfmann]

Given the following example:

      new statement
        .Iam()
        .deny()
        .to('DeletePolicy')
        .to('DeletePolicyVersion')
        .to('CreatePolicyVersion')
        .to('SetDefaultPolicyVersion')

It'd be great if the the argument for to would be fully typed, so that the editor / IDE could auto-complete permissions. I think it's fairly striaghtforward for the full permission names, but rather complicated for wildcards (e.g. .to('Delete*') to still be considered valid for Typescript. Perhaps literal types could help with that.

[udondan]

Interesting idea. But I wonder if it's good to provide the same functionality in multiple ways.

Actually, I made the to method only public, because not all actions are documented and therefore not all actions are covered with distinct toXxx methods. But I never expected it to be used like in your example. 😸 You know you can write it like this?:

new statement.Iam()
  .deny()
  .toDeletePolicy()
  .toDeletePolicyVersion()
  .toCreatePolicyVersion()
  .toSetDefaultPolicyVersion();

I'll have a look and try literal types, but I'm not sure JSII will like this. Wondering how this would be translated to other languages.

[skorfmann]

You know you can write it like this?:

Hehe - I almost forgot about these methods :D - Still, I think literal types could be quite interesting for Typescript users.

I'll have a look and try literal types, but I'm not sure JSII will like this. Wondering how this would be translated to other languages.

I'm almost certain jsii won't like that :)

[udondan]

Interestingly this compiles with jsii. Not sure it would be usable though. Wouldn't be the first time something passes jsii building and then throws up when imported.

But my first quick test shows literal types are of no use at all. Because, again, the to method is actually there for undocumented actions and therefore needs to allow any string. So the type would need to look like this:

type Test = 'Foo' | 'Bar' | 'and 8722 more strings here' | string;

And while code suggestion and auto-completion does work for pure literal types, with the fallback of string in the end, nothing of this does work (at least in VS Code)

It would only work if there are two seperate methods, one supporting all the literal types and one for fallback.

Still, I think literal types could be quite interesting for Typescript users.

Could you elaborate on how this is benefitial? You already get completion/suggestion for all the distinct methods which include detailed documentation on which resources and conditions can be used in conjunction.

[udondan]

I prepared a PR just to see how this would look.