Expose async-function argument type

[viktorlott]

We are exposing the async-function argument type for jsDoc
type declaration support. This means that we now could do:
npm i -D @types/github-script@github:actions/github-script
and the add:
@param {import('@types/github-script').AsyncFunctionArguments} AsyncFunctionArguments.

This could obviously be done in other ways too, like using
@typed-actions/github-script instead. But it seems better
to use the actual source repository instead of a third-party
library to import the type declaration.

[joshmgross]

👋 Hey @viktorlott,

This is definitely an interesting idea, but I'm concerned this would push users in the wrong direction. If you're writing fully typed scripts and creating composite actions, you're probably better off just writing your own action - https://github.com/actions/typescript-action

Could you share a bit more about your use case?

[homura]

actions/typescript-action is too heavy for someone just wants to create a non-generic workflow.

Could you share a bit more about your use case?

For me, what I want is for the editor to be able to intelligently suggest when writing a workflow, because github, context and so on have too many APIs, and being able to suggest intelligently would help to avoid switching back and forth between the document and the code

Additionally, the exported types maybe an alternative to issue #294

[viktorlott]

Hey @joshmgross, I totally see where you're coming from regarding the typical use of actions/github-script. But here's another angle to consider: in policy-driven or restrictive organizations where only approved actions are allowed (like actions/github-script in our case), it's vital for a repository owner to maintain trust and reliability in their limited set of dependencies. Exposing the AsyncFunctionArguments type would help us achieve this (by not having to import a third-party library that's not approved by the organization), and also provide additional benefits like better code organization (e.g. by utilizing jsDocs). I know it's a very niche argument for it, but this is the main reason why I wrote this.

[joshmgross]

@viktorlott I'm okay with adding these types, but I'd like to think a bit more about how extensively we document alternative setups. I still think it pushes users in the wrong direction about how to use this action, so I'm reluctant to document it as something we fully support and encourage.

Would you be willing to remove the documentation in docs/alternative-setup.md?
We could put it in an discussion for now for users adopting more advanced scenarios.

[viktorlott]

@joshmgross Oh hey, I totally forgot about this PR.

Would you be willing to remove the documentation in docs/alternative-setup.md?
We could put it in a discussion for now for users adopting more advanced scenarios.

I understand what you mean, and I'm totally fine with that; so I'll push a revision of this when I get home from work. Cheers!

[yusoh]

<title>Hello World!</title>

Hello World!

We are using Node.js , Chromium , and Electron .