feat(ai): refresh customProvider and createProviderRegistry to support file and skill upload abstractions#14284
Conversation
…der and createProviderRegistry
| languageModels: { | ||
| 'gpt-4o-mini': openai.responses('gpt-4o-mini'), | ||
| }, | ||
| files: openai.files(), |
There was a problem hiding this comment.
idea for future work: what if we had a files composite that can upload to several providers at once?
| }; | ||
| ...(resolvedFiles != null ? { files: () => resolvedFiles } : {}), | ||
| ...(resolvedSkills != null ? { skills: () => resolvedSkills } : {}), | ||
| } as any; // necessary workaround to satisfy the complex return type while maintaining type safety |
There was a problem hiding this comment.
we should avoid this - it is possible to do this without any (see other implementations)
There was a problem hiding this comment.
@lgrammel I know, and I don't like this, but it was the only way I found to make this work:
Also custom provider implements provider so is there the issue of files/skills being optional on the custom provider instance (when using it)?
The code here is directly related to this point: It ensures that an unconditional call to files() or skills() on the custom provider doesn't cause a TypeScript error if one of the included providers have the respective method. This creates better DX, the same way that e.g. when you use the AnthropicProvider you can unconditionally call the two methods because AnthropicProvider has them, even though ProviderV4 only maybe has them.
You can test this behavior with e.g. examples/ai-functions/src/registry/upload-skill-custom-provider.ts: Change anthropic.skills() to e.g. google.skills(), and you'll immediately get a type error because Google doesn't support skills, so you can't just call the method unconditionally.
lgrammel
left a comment
There was a problem hiding this comment.
Looking good except for the any.
Also custom provider implements provider so is there the issue of files/skills being optional on the custom provider instance (when using it)?
Background
customProviderandcreateProviderRegistryhad gaps in provider capability coverage:customProviderhad no way to attach a provider'sfilesorskillsinterfaces,createProviderRegistrywas missingvideoModelsupport entirely, and neither exposedfiles/skillsaccess through the registry abstraction. This made it impossible to use file and skill upload APIs consistently through these provider management utilities.Summary
customProvider: Addedfilesandskillsoptions.createProviderRegistry: AddedvideoModel(providerId:modelId),files(providerId), andskills(providerId)methods.ai-functionsexamples.ai-e2e-nextupload-file route to usecreateProviderRegistryinstead of a hand-rolled provider map.Fully backward compatible.
Manual Verification
Run the new examples.
Checklist
pnpm changesetin the project root)Future Work
N/A
Related Issues
N/A