API Types

Plugins Plugin Development
1

This sort of thing is over my head but it’s something I’m willing to learn and put work into. I just don’t know where/how to begin. At the moment, I typically write out my own IPluginApi with the components, libs, and whatever else I need. After writing multiple plugins, it becomes a bit of a chore.

Ideally, it would be great to define components (and eventually all those GQL functions) with their proper types, and then for plugin developers to add a simple types dependency into their project e.g. yarn add --dev @types/stash

I was looking at pluginApi.d.ts and saw the loadableComponents namespace with some interfaces provided to the SceneCard and ScenePreview components. Out of curiosity, because I’m totally uneducated on this, is it possible to export the ISceneCardProperties from its original file then import it into pluginApi.d.ts so things wont have to be updated in two places?

Any thoughts would be greatly appreciated.

2

I’m even less knowledgeable than you but I believe @Valkyr has some of that work done here https://github.com/Valkyr-JS/StashPluginTemplate/tree/main/types.

1 Like
3

In theory, you would be able to directly import the typings from the ui folder but it might be picky on transclusions, but it might be easier and possible to just generate type definitions from the TSX

Try importing the generated .d.ts files as they are only definition files and include no code

4

Sorry, didn’t see the notification about this until just now!

I’m still working types out as I go. I started with copying the pluginApi.d.ts same as you. And like you, found that there are bits spread out everywhere like with the scene card properties types.

I’ve not seen a way to pull that out other than literally copy/pasting, however that can be a rabbit hole of pulling parts from separate files. It also isn’t future proof if the API changes.

I’ve started using Zod for my latest plugin. Rather than just defining types, you write a schema describing the response, and it checks it at runtime to ensure the response fits the model you expect. This makes it easier to identify changes in API schema and handle any errors. It’s probably overkill as the API doesn’t seem to change that often other than additions, and if you’re still getting your head around types then this might be a little much.

For straight up types, it could be an idea to have a dedicated repo for us to manage plugin API types. We can add things as we go which should save each other time. I’d be happy to host and give you write access, or equally vice versa.