Allow typeholes on functions

[andrew-ironforge]

I do not know if this is possible but this would also be life-changing: scan the prototype of an object to see if it contains any functions, and then optionally add those to an interface. For example, I tried this to see if it worked (it did not):

Notice the dozens of functions in the debug window.... Since this library doesn't have a types declaration, I have to go through and "discover" what functions I can call. I'm wondering whether there could be a setting in the typehole function call? e.g. call a typehole like typehole.t3<ISomeType>(valueBeingInspected, 'includeProtoFunctions')

Alternatively, add some kind of config options parameter for further extensibility:

typehole.t3<ISomeType>(valueBeingInspected, {
  includePrototypeFunctions: true,
  id: 'ISomeType' // read below
  export: true // The type being generated is automatically set to be exported from the file
})

I saw you had some issues with using the function names to address typeholes? Consider making some kind of string identifier instead if possible. I could see a scenario where I might want to have multiple typeholes write to the same destination type (eg an API error response that is received in different functions, but is ultimately the same type).

Using the typeholes function name seems a bit odd to me, when you could make a string identifier which is equal in value to the name of the interface/type/class etc being written to.

[rikukissa]

I've actually thought of this before, but creating an accurate type signature for a runtime function value is, if not impossible, extremely difficult. Detecting a value is a function and creating a generic type like (...args: any[]) => any would be possible though.

I saw you had some issues with using the function names to address typeholes? Consider making some kind of string identifier instead if possible. I could see a scenario where I might want to have multiple typeholes write to the same destination type (eg an API error response that is received in different functions, but is ultimately the same type).

That use case could possibly be solved with the same approach I described here. Define one interface and refer to it in multiple typeholes.

Using the typeholes function name seems a bit odd to me, when you could make a string identifier which is equal in value to the name of the interface/type/class etc being written to.

Yeah, I agree – it's a bit of an odd design decision. The first idea I had for the usage of this tool was actually something like this:

const value: ??? = await getData() 

where the ??? would then be automatically replaced by the extension. At the moment this type of syntax isn't really possible to achieve however, as TypeScript compiler doesn't support plugins. As the next evolution, I did something like this

typehole(await getData())

but this of course doesn't work when you have more than one typehole. I guess

typehole('1', await getData())

would work and be a bit more convenient than the current Proxy implementation.