Some ideas for `typegen.js`

[PFiS1737]

Hi, I have some issue reports and ideas regarding typegen.js:

1. Instead of mentioning inheritance in comments, use type declarations like ---@class (exact) ui.Line : ui.Style to indicate inheritance relationships.

2. The parameter tables seem unnecessary — most of the time they simply duplicate the function signature. We could print the table only for signatures that have a Note, or perhaps find a better way to include the note?

3. It seems that some methods and properties are still missing from the type definitions, such as the base of Url, Command.PIPED, etc.

4. The utility functions in yazi-plugin/preset/ya.lua are not included in the type definitions.

[sxyazi]

use type declarations like ---@class (exact) ui.Line : ui.Style to indicate inheritance relationships.

Does it support multiple inheritance? If not, this may limit future expansion. Also, some properties or methods need to be set to private. For instance, ui.Span should not inherit the patch() method from ui.Style, which is currently implemented via a "Private" field. Does it support that?

The parameter tables seem unnecessary

It's at the very end of the comments without blocking any content before, so shouldn't a big deal, though we could find a way to remove it. Currently, the important thing is the "Available" field in the table, for example:

• Unix-like systems only, such as

  yazi-rs.github.io/docs/plugins/types.md

  Line 305 in 9403ab0

  | Available | Unix-like systems only |

• Async context only, such as

  yazi-rs.github.io/docs/plugins/utils.md

  Line 274 in 9403ab0

  | Available | Async context only |

Command.PIPED

Yes, currently constants like Command.PIPED, Command.NULL, and Command.INHERIT are missing.

base of Url

The utility functions in yazi-plugin/preset/ya.lua

They are currently private, intentionally undocumented APIs so that they can be changed in the future.

[sxyazi]

Maybe for | Available | Async context only | we can use the ---@async annotation, but not sure how it works yet well, seems just an editor's hints, I think that should be enough

[PFiS1737]

Thank you for providing more information.

Regarding private fields, There doesn't seem to be a good solution, so let's keep things as they are.

As for "Async context only", I don't think the ---@async annotation is a good solution. It’s intended to mark functions as asynchronous in an otherwise synchronous context, not to indicate that something must be used within an async context. I think a better approach might be simply using plain text, or an additional NOTE: tag for clarification.