Editor SDKs
Edit this page on GitHubSmart IDEs (such as VSCode or IntelliJ) require special configuration for TypeScript to work when using Plug'n'Play installs. This page intends to be a collection of settings for each editor we've worked with - please contribute to this list!
The editor SDKs and settings can be generated using yarn dlx @yarnpkg/sdks
(or yarn sdks
if you added @yarnpkg/sdks
to your dependencies). Its detailed documentation can be found on the dedicated page.
Generally speaking:
- Use
yarn sdks vscode vim
to generate both the base SDKs and the settings for the specified supported editors. - Use
yarn sdks base
to generate the base SDKs and then manually tweak the configuration of unsupported editors. - Use
yarn sdks
to update all installed SDKs and editor settings.
Tools currently supported
Note: Be aware that only the SDKs for the tools present in your root package.json will be installed (the tool won't look at the dependencies from your other workspaces). So don't forget to run the command again should you change the set of tools used by your project!
Extension | Required package.json dependency |
---|---|
Builtin VSCode TypeScript Server | typescript |
vscode-eslint | eslint |
prettier-vscode | prettier |
flow-for-vscode* | flow-bin |
astro-vscode | astro |
* Flow is currently incompatible with PnP.
If you'd like to contribute more, take a look here!
Editor setup
VSCode
To support features like go-to-definition a plugin like ZipFS is needed.
- Run the following command, which will generate a new directory called
.yarn/sdks
:
yarn dlx @yarnpkg/sdks vscode
For safety reason VSCode requires you to explicitly activate the custom TS settings:
Press ctrl+shift+p in a TypeScript file
Choose "Select TypeScript Version"
Pick "Use Workspace Version"
Your VSCode project is now configured to use the exact same version of TypeScript as the one you usually use, except that it will now be able to properly resolve the type definitions!
Note that VSCode might ask you to do Step 3 again from time to time, but apart from that your experience should be mostly the same as usual. Happy development!
VIM
To support features like go-to-definition a plugin like vim-rzip is needed.
coc.nvim
Run the following command, which will generate a new directory called .yarn/sdks
and create a .vim/coc-settings.json
file:
yarn dlx @yarnpkg/sdks vim
Note that if you're using coc-tsserver
then you might want to check what version it uses by running :CocCommand tsserver.chooseVersion
— make sure that "Local version" is selected, not "Bundled with coc-tsserver".
Neovim Native LSP
Note: Requires Neovim version >=0.6
Run the following command, which will generate a new directory called .yarn/sdks
:
yarn dlx @yarnpkg/sdks base
With the .yarn/sdks
in place TypeScript support should work out of the box with nvim-lspconfig and theia-ide/typescript-language-server.
Emacs
The SDK comes with a typescript-language-server wrapper which enables you to use the ts-ls LSP client.
- Run the following command, which will generate a new directory called
.yarn/sdks
:
yarn dlx @yarnpkg/sdks base
- Create a
.dir-locals.el
with the following content to enable Flycheck and LSP support and make sure LSP is loaded after local variables are applied to trigger theeval-after-load
:
((typescript-mode
. ((eval . (let ((project-directory (car (dir-locals-find-file default-directory))))
(setq lsp-clients-typescript-server-args `("--tsserver-path" ,(concat project-directory ".yarn/sdks/typescript/bin/tsserver") "--stdio")))))))
- Do note, that you can rename
:local
as you'd like in case you have SDKs stored elsewhere (other than.yarn/sdks/...
) in other projects.
Caveat
Since the Yarn packages are kept within their archives, editors need to understand how to work with such paths should you want to open the files (for example when command-clicking on an import path originating from an external package). This can only be implemented by those editors, and we can't do much more than opening issues to ask for this feature to be implemented (for example, here's the VSCode issue: #75559).
As a workaround, you can run
yarn unplug pkg-name
to instruct yarn to unzip the package, which will re-enableGo to definition
functionality for the specific package.