Theia API Documentation v1.73.0
    Preparing search index...

    Contribution point for the Extensions view. Each contribution represents one artifact type (e.g. extension, mcp-server, future skill) and supplies entries to the relevant sections of the view.

    Contributions implement only the modes they participate in. A contribution that has no concept of "built-in", for example, simply omits resolveBuiltIn.

    Each returned TreeElement carries its own render(host) - the contribution controls how its entries look. The view groups results by contribution type (using displayName as the group header) when more than one contribution yields entries for a section.

    Implements

    Index

    Constructors

    Properties

    displayName: string = ...

    Human-readable label used as the group header in the view.

    fetchService: RegistryFetchService
    hoverService: HoverService
    installClient: SkillInstallClientImpl
    installService: SkillInstallService
    logger: ILogger
    messageService: MessageService
    onDidChange: Event<void> = ...

    Fired when the contribution's entries change (e.g. after install, refresh, or preference update).

    onDidChangeEmitter: Emitter<void> = ...
    priority: 200

    Skills sort below MCP servers (priority 100), which in turn sort below extensions.

    searchFilter: RegistrySearchFilter
    searchToken: "@skills" = '@skills'

    @-prefixed token recognised in the search query to scope results to this contribution alone. Composable with the existing @installed / @builtin / @recommended mode tokens (e.g. @installed @mcp shows installed servers of type mcp-server only). When no type token appears in the query, all contributions are shown.

    Contributors are expected to start the token with @; without the prefix the search model may treat the token as a plain word in the free-text part of the query.

    toDispose: DisposableCollection = ...
    type: "skill" = 'skill'

    Stable, machine-readable identifier for the artifact type.

    windowService: WindowService

    Methods

    • Entries matching a user search. Each result carries its own searchableText so the view can rank hits from all contributions against a single query. Omit if this type does not participate in search.

      Contributions may ignore query when their internal state already reflects the current query (e.g. the VSX adapter, whose model is kept in sync with the search bar via the singleton VSXExtensionsSearchModel). In that case the contribution is expected to yield its current result set and let the view's cross-contribution fuzzy ranker handle the actual ordering.

      Parameters

      Returns Promise<Iterable<SearchResult, any, any>>

    • Runs a mutation action, reporting success or failure via the message service and refreshing the view once it settles. Kept here (rather than in the entries) so the view stays in sync with on-disk state after every action.

      Parameters

      • action: () => Promise<void>
      • successMessage: string

      Returns Promise<void>