Open Silic0nS0ldier opened 1 month ago
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
Support resolving TypeScript language service plugins relative to the
tsconfig.json
that lists them. Right now only plugins relative to the TypeScript instance are (implicitly) allowed, which is problematic when using a strict package manager like pnpm.To be clear, I'm not asking for this to be enabled by default. That would go against the existing VSCode defaults. It would be nice is VSCode created a notification when a plugin could not be resolved and local plugin loads was disabled, so that devs are aware and can make the necessary configuration changes, though that is a bigger ask.
As far as implementing this, TypeScript itself can perform correct resolution (needs
allowLocalPluginLoads: true
) and the TS web implementation of the language server actually has this wired up partially.https://github.com/microsoft/vscode/blob/a14300ec9f7d04fbbaa9f896d46626110baa2b90/extensions/typescript-language-features/web/src/webServer.ts#L51
Example
/Users/__/__/__/web/
/Users/__/__/__/
/Users/__/__/__/web/node_modules/typescript
/Users/__/__/__/node_modules/.pnpm/typescript@5.5.4/node_modules/typescript
/Users/__/__/__/web/node_modules/@__/__-plugin
/Users/__/__/__/web/tsconfig.json
In this scenario the workspace TypeScript version is being used. Since the resolved path for the TypeScript package is outside the
web/
directory, the plugin cannot be resolved.To get around this issue we've added
@__/__-plugin
to pnpm's public hoist patterns (so it appears in/Users/__/__/__/node_modules
) which isn't ideal. It's the same kind of issue as what ESLint (the tool itself, not the extension specifically) has had historically (a big enough issue that even in pnpm v9*eslint*
is a default public hoist pattern).An alternative workaround is adding the plugin path (or the
node_modules
containing it) totypescript.tsserver.pluginPaths
however this is an imperfect, brittle, and at worst incorrect (wrong plugin version could be resolved) solution.Related
45856
46443