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

[FileSystemProvider] Provide API for accessing from other extensions via URIs #51528

Closed
mkloubert opened this issue Jun 9, 2018 · 2 comments
Closed
Assignees
Labels
*duplicate Issue identified as a duplicate of another issue(s) remote Remote system operations issues

Comments

@mkloubert
Copy link

Currently an extension author is "only" able to register an own FileSystemProvider by using vscode.workspace.registerFileSystemProvider() function.

But currently there seems to be no way to access them from "outside" / from other extensions.

I currently have requests to support linters and formatters in my extension vscode-remote-workspace, but I am not sure if this should not be the work of authors, who have created these linters and formatters.

My idea is to create a new namespace like vscode.fs, similar to Node.js:

import * as vscode from 'vscode';

const PROVIDER: vscode.FileSystemProvider = vscode.fs.getFileSystemProviderByScheme('sftp');
if (PROVIDER) {
    // found
} else {
    // not found
}

Maybe there should (also or only) be some public functions to access these providers, without needing the objects, which might be better.

Files and directories (also local ones) could be accessed by Uris.

export namespace vscode {
    export namespace fs {
        export declare function copy(source: vscode.Uri, destination: vscode.Uri, options: { overwrite: boolean }): vscode.Thenable<void>;

        export declare function createDirectory(uri: vscode.Uri): vscode.Thenable<void>;

        export declare function delete(uri: vscode.Uri): vscode.Thenable<void>;

        // returns the full ID of the extension, that supports the scheme
        // 
        // return (null) or (undefined) if no extension was found
        export declare function getExtensionOfFileSystemScheme(scheme: string): string;

        export declare function isFileSystemSchemeSupported(scheme: string): boolean;

        export declare function readDirectory(uri: vscode.Uri): vscode.Thenable<[string, vscode.FileType][]>;

        export declare function readFile(uri: vscode.Uri): vscode.Thenable<Uint8Array>;

        export declare function rename(oldUri: vscode.Uri, newUri: vscode.Uri, options: { overwrite: boolean }): vscode.Thenable<void>;

        export declare function stat(uri: vscode.Uri): vscode.Thenable<vscode.FileStat>;

        export declare function writeFile(uri: vscode.Uri, content: Uint8Array, options: { create: boolean, overwrite: boolean }): vscode.Thenable<void>;
    }
}

As you can see, the functions are mappers of the methods of FileSystemProvider interface, which would (re-)throw their exceptions, if occurred.

If a scheme is not supported, and those are tried to be used, a new kind of FileSystemError, like 'SchemeNotSupported' exception should be thrown,

Authors could use external FileSystemProviders using the common way, by uusing the extensionDependencies property in their package.json:

{
  "name": "vscode-my-awesome-extension",
  "displayName": "My Awesome Extension",

  // ...

  "extensionDependencies": [
    "mkloubert.vscode-remote-workspace"
  ]
}

Ok, some functions name are a little bit "strange", but this is only an idea.

@jrieken
Copy link
Member

jrieken commented Jun 11, 2018

/duplicate of #48034

@vscodebot vscodebot bot added the *duplicate Issue identified as a duplicate of another issue(s) label Jun 11, 2018
@vscodebot
Copy link

vscodebot bot commented Jun 11, 2018

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
*duplicate Issue identified as a duplicate of another issue(s) remote Remote system operations issues
Projects
None yet
Development

No branches or pull requests

2 participants