| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
| } | ||
|
|
||
| /** The selected TypeScript installation, bound to one language server initialization. */ | ||
| export interface TypeScriptSDK { |
There was a problem hiding this comment.
Type names also valid for bikeshedding
Sorry, something went wrong.
There was a problem hiding this comment.
I trust your judgement for all bikesheddable naming
Sorry, something went wrong.
| export interface ExtensionAPI { | ||
| onLanguageServerInitialized: Event<void>; | ||
| export interface APIModules { | ||
| [exportPath: string]: unknown; |
There was a problem hiding this comment.
I opted to have a fallback here so you could use a newer import path than your types expose, but I'm not sure if there's much reason not to just install the latest types as soon as you want to use the latest features. Would it be better to remove this?
Sorry, something went wrong.
There was a problem hiding this comment.
Package-change detection can permit unverifiable versions and abort restarts when a manifest becomes unreadable.
Review effort: Balanced
Findings: 2
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Our VS Code extension already exposes a way for third-party extensions to connect a TypeScript API client to the user's currently running TypeScript LSP server. But since the API client and server need to be version-matched, and users can choose between a workspace version of TypeScript or one of potentially multiple built-in versions for their LSP server, the VS Code extension really needs to give those third-party extensions a way to resolve the correct version of the API client to use.
Previously, third-party extensions would do something like this:
With this PR, that will change to:
Of course, this means that your API client types are effectively a devDependency representing a peerDependency whose versions could be mismatched at runtime. Extensions should type check and test against multiple versions, and use runtime probes to conditionally access newer client features:
More guidance on version compatibility will be documented soon.
Doing the same thing from a third-party LSP server
If you're launching an LSP server that connects to the TypeScript API, the method above won't help you, since you can't access the extension API from another process. For convenience, the same typed module loader is exported from "typescript/vscode". If you're bundling your extension, you can import from that module without bundling in the actual API client:
VSIX structure
This changes VSIX packaging to include node_modules containing typescript and @typescript/typescript-${os}-${arch} instead of the bare tsc executable in lib/.
Manually tested the LSP + an API connection with the packed VSIX, that plus the nightly VSIX, and local dev, but extra eyes on the output are appreciated.