foo.ts

import * as vscode from 'vscode';
import * as types from './index';
import { AzExtTreeItem } from './src/tree/AzExtTreeItem';

interface TreeNodeConfiguration {
    readonly label: string;
    readonly description?: string;
    readonly icon?: vscode.ThemeIcon;
    readonly contextValue?: string;
}

// ex: Static Web App
interface ApplicationResource extends TreeNodeConfiguration {
    getChildren?(): vscode.ProviderResult<AzExtTreeItem[]>;
    resolve?(): Thenable<void>;

    resolveTooltip?(): Thenable<string | vscode.MarkdownString>;
}

export interface GroupableApplicationResource extends ApplicationResource {
    readonly rootGroupConfig: TreeNodeConfiguration;
    readonly subGroupConfig: {
        readonly resourceGroup: TreeNodeConfiguration;
        readonly resourceType: TreeNodeConfiguration;
        readonly [label: string]: TreeNodeConfiguration; // Don't need to support right off the bat but we can put it in the interface
    }
}

export type LocalResource = types.AzExtTreeItem;

export interface ApplicationResourceProvider {
    provideResources(subContext: types.ISubscriptionContext): vscode.ProviderResult<GroupableApplicationResource[] | undefined>;
}

export interface ApplicationResourceResolver {
    resolveResource(resource: GroupableApplicationResource): vscode.ProviderResult<void>;
}

export interface LocalResourceProvider {
    provideResources(): vscode.ProviderResult<LocalResource[] | undefined>;
}

// called from a resource extension (SWA, Functions, etc)
export declare function registerApplicationResourceResolver(
    provider: ApplicationResourceResolver,
    resourceType: string,
    resourceKind?: string,
): vscode.Disposable;

// Resource Groups can have a default resolve() method that it supplies, that will activate the appropriate extension and give it a chance to replace the resolve() method
// ALSO, it will eliminate that default resolver from future calls for that resource type

// called from host extension (Resource Groups)
// Will need a manifest of extensions mapping type => extension ID
export declare function registerApplicationResourceProvider(
    provider: ApplicationResourceProvider,
    featureExtension: ExtensionManifestEntry, // Or similar?
    resourceType: string | 'other', // Maybe this | 'other'
    resolver?: ApplicationResourceResolver, // Maybe? // Default resolver?
    resourceKind?: string,
): vscode.Disposable;

// resource extensions need to activate onView:localResourceView and call this
export declare function registerLocalResourceProvider(
    resourceType: string,
    provider: LocalResourceProvider
): vscode.Disposable;

interface ExtensionManifestEntry {
    extensionId: string;
    minimumExtensionVersion?: string;
    resourceTypes: {
        resourceType: string,
        resourceKind?: string,
    }[];
}

export const ExtensionsManifest: ExtensionManifestEntry[] = [

];

RE resourceType on local resources--I think it can be whatever we want it to be, however I'd try to come up with something that roughly matches the resource type scheme Azure does, i.e. Microsoft.ContainerRegistry/registries. For functions, maybe Microsoft.Web/sites/local or something like that.

RE ISubscriptionContext, I'm still thinking about it. For one thing, I think it needs to be a member on every node, not like today where we do a ton of parent.parent.subscriptionContext or similar. In the strictest sense of an extensibility model, each feature extension would just enumerate subscriptions on its own, but that obviously would be a significant perf hit.

It sorta sounds like we're gonna do only Azure stuff on this page, though. So maybe we do registerAzureResourceProvider(...), and it implements provideResources(subscriptionContext: ISubscriptionContext): vscode.ProviderResult<GroupableApplicationResource[] | undefined>; i.e. the subscription context is passed to it.