anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[PR #5003] fix: correct Provider type in chat.params plugin hook #11200

New Issue
Closed
opened 2026-02-16 18:16:00 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:16:00 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/5003

State: closed
Merged: Yes

Summary

Fixes incorrect TypeScript types for the provider parameter in the chat.params plugin hook.

Closes #2392

Problem

The chat.params hook type uses Provider directly, but at runtime the hook receives a wrapper object with the provider info nested under an info property.

Before (incorrect):

provider: Provider  // expects provider.id

Runtime structure:

{
  source: "env" | "config" | "custom" | "api"
  info: Provider
  options: Record<string, any>
}

Solution

Added a new ProviderContext type that matches the actual runtime structure and updated the chat.params hook signature to use it.

export type ProviderContext = {
  source: "env" | "config" | "custom" | "api"
  info: Provider
  options: Record<string, any>
}

Changes

  • Added ProviderContext type export
  • Updated chat.params hook to use ProviderContext instead of Provider

Notes

  • The auth.loader callback correctly uses Provider (it receives raw provider info from the database, not the wrapper)
  • This is a breaking change for any plugins that incorrectly relied on the wrong types, but those plugins wouldn't have worked correctly at runtime anyway

Alternative Approach

This PR fixes the types to match the current runtime behavior. An alternative would be to change the runtime to pass provider.info directly (the raw Provider), matching how auth.loader works:

// Current runtime (wrapper object)
provider: { source, info: Provider, options }

// Alternative runtime (raw Provider, like auth.loader)
provider: Provider

The alternative would be a cleaner API but would be a breaking runtime change for existing plugins that have worked around the type mismatch by accessing provider.info.id etc.

**Original Pull Request:** https://github.com/anomalyco/opencode/pull/5003 **State:** closed **Merged:** Yes --- ## Summary Fixes incorrect TypeScript types for the `provider` parameter in the `chat.params` plugin hook. Closes #2392 ## Problem The `chat.params` hook type uses `Provider` directly, but at runtime the hook receives a wrapper object with the provider info nested under an `info` property. **Before (incorrect):** ```typescript provider: Provider // expects provider.id ``` **Runtime structure:** ```typescript { source: "env" | "config" | "custom" | "api" info: Provider options: Record<string, any> } ``` ## Solution Added a new `ProviderContext` type that matches the actual runtime structure and updated the `chat.params` hook signature to use it. ```typescript export type ProviderContext = { source: "env" | "config" | "custom" | "api" info: Provider options: Record<string, any> } ``` ## Changes - Added `ProviderContext` type export - Updated `chat.params` hook to use `ProviderContext` instead of `Provider` ## Notes - The `auth.loader` callback correctly uses `Provider` (it receives raw provider info from the database, not the wrapper) - This is a breaking change for any plugins that incorrectly relied on the wrong types, but those plugins wouldn't have worked correctly at runtime anyway ## Alternative Approach This PR fixes the types to match the current runtime behavior. An alternative would be to change the runtime to pass `provider.info` directly (the raw `Provider`), matching how `auth.loader` works: ```typescript // Current runtime (wrapper object) provider: { source, info: Provider, options } // Alternative runtime (raw Provider, like auth.loader) provider: Provider ``` The alternative would be a cleaner API but would be a breaking runtime change for existing plugins that have worked around the type mismatch by accessing `provider.info.id` etc.
yindo added the pull-request label 2026-02-16 18:16:00 -05:00
yindo closed this issue 2026-02-16 18:16:00 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#11200
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?