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[] = [

];

export declare function registerApplicationResourceProvider(
    resourceType: string,
    provider: ApplicationResourceProvider
): vscode.Disposable;

We'll need to be able to register a provider for multiple resourceTypes. And some cases like functions currently have more complex logic which check values within the ARM GenericResource type. So maybe string | string[] | (resource: GenericResource) => boolean?

Can't the same extension just call registerApplicationResourceProvider multiple times?

That should work for the multiple resources case 👍

export declare function registerLocalResourceProvider(
    resourceType: string,
    provider: LocalResourceProvider
): vscode.Disposable;

I'm not sure I understand what resourceType would be for local resources. Could you give an example? What would be the resourceType for an Azure Functions local project?

In order for the extensions to resolve resources, they'll need an ISubscriptionContext. Are we planning to pass this down somewhere? Pass it down as part of IActionContext?

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.