Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow requestSchema to return Promise #1004

Open
vaclavHala opened this issue Feb 5, 2024 · 0 comments
Open

Allow requestSchema to return Promise #1004

vaclavHala opened this issue Feb 5, 2024 · 0 comments

Comments

@vaclavHala
Copy link

Is your enhancement related to a problem? Please describe.

We integrate vscode-yaml to provide language support for our yaml project configuration files. Nature of the config is such that you can't decide just by looking at the name of the file what "type" of configuration file it is. To find if given file is even part of our project configuration and if so what role it plays (thus what schema to apply) we need to invoke some async code, which we can't do because requestSchema requires immediate string result.

Describe the solution you would like

We'd like the ExtensionAPI.registerContributor to be extended like this

  registerContributor(
    schema: string,
    requestSchema: (resource: string) => Promise<string> | string,  // << Allows `Promise<string>` here
    requestSchemaContent: (uri: string) => Promise<string> | string,
    label?: string
  ): boolean;

this change should be backwards compatible as simple string result is still allowed.

Looking at the history I see requestSchemaContent also started as allowing only string return but in time was extended to also allow Promise<string> - was there some reason to keep requestSchema synchronous only or was there simply no usecase for also extending it so it was left as is?

Describe alternatives you have considered

It is possible to work around this limitation by eagerly caching results for requestSchema so when this callback is invoked we can return the cached value (if already available) but we'd like to fall back to this solution as last resort as it will introduce significant complexity for our implementation and consume extra time+memory for the user (we have to eagerly prefetch everything to have it ready for when requestSchema gets called)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant