Prompt files provider API V2

[pwang347]

No description provided.

[aeschli]

I think we should stick with our resource (URI) based approach

• our loading-on demand approach depends on reading resources
• References in prompt files use resource paths
• so we will turn everything into resources anyways
• the API is just some convenience for (what I think) limited number of extensions that want to provide dynamic prompt files.
  Extensions can already implement TextDocumentContentProvider and FileSystemProviders
• we don't want to define API types for the header, it's not practical given how quickly we evolve.

[aeschli]

Having the headers specified in the vscode API is problematic and undesirable.

• vscode API needs to be backward compatible, so we can't easily remove or rename properties or their values (e.g. tool names)
• every addition needs to be discussed in a API call

So what providers provide should just be a string, no structure, that then will be parsed on the core side

[pwang347]

What do you think about providing something like this?

interface IPromptFileContent {
  header: {
    // for supported properties, see <link> (documentation will have a table showing what versions various properties were added)
    [key: string]: unknown;
  },
  body: string;
}

// we can take in either a string as value, or something structured like the above

Happy to discuss more; I think my main problem with the current contract is that anyone who is interested in adding dynamic content needs to get into the business of managing files as well as frontmatter formatting (and potentially parsing), which feels a bit wrong IMO for something quick and dirty.

[pwang347]

pushed changes above, also updated the URI handling so we can take a look tomorrow - thanks!

[aeschli]

Putting resource content in the query is problematic and a misuse of a URI.

• the query is part of the resource identifier. foo:///bar?hello and foo:///bar?world should not represent two different resources, but the same one (identified e.g. by 'foo:///bar')
• there's a limit on how long URIs can be typically

Maybe the better model s to create TextDocuments on the extension and share contents like that.

[pwang347]

I'll need to explore this a bit more, from playing around with it when I tried opening untitled documents they would sometimes appear in the windows tab unexpectedly for me.

[pwang347]

Basically, I see this entrypoint as our internal recommendation for how users should be implementing ephemeral resources since I think it is a valid use case (not everyone will want to care about managing prompt files, the end goal is to inject instructions, agents, etc.)