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

Track TS Server Extension API #22101

Closed
mjbvz opened this issue Mar 6, 2017 · 4 comments
Closed

Track TS Server Extension API #22101

mjbvz opened this issue Mar 6, 2017 · 4 comments
Assignees
Labels
plan-item VS Code - planned item for upcoming
Milestone

Comments

@mjbvz
Copy link
Collaborator

mjbvz commented Mar 6, 2017

No description provided.

@mjbvz mjbvz added the plan-item VS Code - planned item for upcoming label Mar 6, 2017
@mjbvz mjbvz added this to the March 2017 milestone Mar 6, 2017
@mjbvz mjbvz self-assigned this Mar 6, 2017
@kieferrm kieferrm mentioned this issue Mar 6, 2017
58 tasks
@mjbvz
Copy link
Collaborator Author

mjbvz commented Mar 22, 2017

Our current proposal for the implementation:


The agreement with the TS team was that plugins will come through VSCode extensions. For example, if a user wants enhanced angular language support, they would install an angular VSCode extension that then contributes an angular TSServer plugin. Here's a proposal of how this will be implemented:

In the VSCode TypeScript extension, during activation we pick up a list of contributed TSServer plugins from other installed extension. This list would come from entries in each extension's package.json:

    {
        "contributes": {
            "typescript-plugins": [
                  "tss-angular-plugin",
                  "tss-html-plugin"
            ]
        }
    }

When starting the TypeScript server, the VSCode TypeScript extension will provide a list of plugin that we know about, along with the directories to search for installed plugins:

tsserver -plugins=tss-angular-plugin;tss-html-plugin     --plugin-dirs=/Users/matb/.code/extensions/angular-extension/;...

When TypeScript is being run out of the user's workspace, we would not pass in any plugin dirs. This means that all extension plugins would have to come from the workspace.

When resolving the plugins themselves, typescript would first search adjacent to its own install and then in each of the plugin-dirs. This avoids the potential security issues because we only load a plugin from a user's workspace if they have already trusted the typescript instance in that workspace.

@mjbvz
Copy link
Collaborator Author

mjbvz commented Mar 22, 2017

Closing this since the investigation part is complete. We'll look into prototyping plugin support next month

@mjbvz mjbvz closed this as completed Mar 22, 2017
@kieferrm
Copy link
Member

kieferrm commented Mar 25, 2017

@mjbvz here is a more complete write-up.

Context

The TS server is extensible via plugins. Plugins fall in two categories:

  • better TypeScript or JavaScript support through additional problem analysis and quick fixes
  • support for mixed languages that make use of TypeScript or JavaScript

The first categories of plugins is straight forward. VS Code already knows that the TS server is taking care of TS and JS files. For the second category, configuration is required as VS Code needs to know about the new file types that the TS server can handle.

All plugins need to be installed at locations that the TS server knows. Which of those plugins a TS server uses for a given project is specified in the project's tsconfig.json file. In theory, a TS server could come with VS Code while its plugins come from a node_modules directory in the user's workspace.

Constraints

In order to support TS server plugins in VS Code we need a solution that:

  • allows to configure which file types are supported by the TS server
  • ensures that VS Code does not run any plugins from the user's workspace without the user's explicit confirmation
  • uses the existing mechanisms of the VS Code TypeScript extension

Proposal

TS server plugins will come through VS Code extensions. For example, if a user wants enhanced angular support, they would install the angular VS Code extension that then contributes an angular TS server plugin as well as the file mappings for .ng (and other) files.

VS Code extensions that provide TS server plugins needs to declare a dependency on the VS Code TypeScript extension.

The dependency on the VS Code TypeScript extension will ensure that the VS Code TypeScript extension is activates before any extension that provides TS server plugins. This also ensures that the user could also influence the decision about which TS installation is being used in case there are multiple ones or there is a tsdk setting.

On activation, the VS Code TypeScript extension will pick up a list of contributed TS server plugins from other installed extension. This list comes from entries in package.json files:

    {
        "contributes": {
            "typescript-plugins": [
                  "tss-angular-plugin",
                  "tss-html-plugin"
            ]
        }
		*** TBD file type spec ***
    }

When starting the TS server, the VS Code TypeScript extension will provide a list of known TS server plugins, along with their installation directories:

tsserver -plugins=tss-angular-plugin;tss-html-plugin     --plugin-dirs=/Users/matb/.code/extensions/angular-extension/;...

When resolving the plugins listed in -plugins, the TS server first searches adjacent to its own install and then in each of the -plugin-dirs.

When the TS server is being run out of the user's workspace or is specified through a tsdk entry in the workspace or user settings, the VS Code TypeScript extension will not pass any value for -plugin-dirs. This means, that the TS server can only resolve plugins using the workspace or tsdk location. This avoids any potential security issue because the TS Server will only load plugins from the user workspace or an external local if it itself comes from those locations and has been confirmed by the user.

@egamma
Copy link
Member

egamma commented Apr 30, 2017

extracted feedback on the current support into a separate issue #25769.

@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
plan-item VS Code - planned item for upcoming
Projects
None yet
Development

No branches or pull requests

3 participants