Add explicit return types for plugins that define models, etc #397
Conversation
| @@ -120,7 +122,7 @@ export function chromaRetriever< | |||
| createCollectionIfMissing?: boolean; | |||
| embedder: EmbedderArgument<EmbedderCustomOptions>; | |||
| embedderOptions?: z.infer<EmbedderCustomOptions>; | |||
| }) { | |||
| }): RetrieverAction<z.ZodOptional<typeof ChromaRetrieverOptionsSchema>> { | |||
There was a problem hiding this comment.
This seemed a little funky to me. Should we just make this ChromaRetrieverOptionsSchema?
It looks like we're possibly double-wrapping in an Optional? https://github.com/firebase/genkit/blob/main/js/ai/src/retriever.ts#L164-L168
There was a problem hiding this comment.
When I first made these abstractions in js/ai, I wanted to make as few assumptions as possible. That meant that the options should not be ZodOptional since we do not know what kind of retriever they are building and what options are required vs optional.
IMO, the /ai abstractions should not add a .optional() on the schema and the providers can add them in the custom schema they define (ChromaRetrieverOptionsSchema in this case).
That being said, this code has through many changes and its evident that it no longer holds to that thought. The problem here does not seem to be double wrapping though -- there is no Optional on the ChromaRetrieverOptionsSchema object and it is added by RetrieverAction.
| @@ -185,7 +187,7 @@ export function configurePineconeIndexer< | |||
| textKey?: string; | |||
| embedder: EmbedderArgument<EmbedderCustomOptions>; | |||
| embedderOptions?: z.infer<EmbedderCustomOptions>; | |||
| }) { | |||
| }): IndexerAction<z.ZodOptional<typeof PineconeIndexerOptionsSchema>> { | |||
There was a problem hiding this comment.
This seemed a little funky to me. Should we just make this PineconeIndexerOptionsSchema?
It looks like we're possibly double-wrapping in an Optional? https://github.com/firebase/genkit/blob/main/js/ai/src/embedder.ts#L74-L78
MichaelDoyle
force-pushed
the
model-config-type-safety
branch
from
fd6c532 to
e916bc4
Compare
MichaelDoyle
force-pushed
the
model-config-type-safety
branch
from
e916bc4 to
d449594
Compare
|
@pavelgj friendly ping on this one |
I think this will help folks that want to contribute to the plugins with better type safety. I've seen a few errors go by (or almost go by) related to this.