Allow VS Code Plugin to use workspace Typescript version

Describe the bug The current version of Zod has a compatibility problem with Typescript 4.3. (https://github.com/colinhacks/zod/issues/473)

This is not a big problem, I can just keep using Typescript 4.2 until the problem is fixed by one of the projects. In .ts files, this works fine.

But in Svelte files, I still get the Excessive stack depth error from Typescript 4.3.

I noticed that https://github.com/sveltejs/language-tools/blob/b807aa1fe3bd9cdee78068037decae0d60af292e/packages/svelte-vscode/package.json#L530 defines the Typescript version as '*', and looking on my hard drive at the extension files ~/.vscode/extensions/svelte.svelte-vscode-105.1.0/node_modules/typescript/package.json, I can see that it indeed installed Typescript 4.3.2

Is it possible that the Extension uses this Typescript version, and thus shows me the error?

To Reproduce

I made a very small reproduction: https://github.com/danieldiekmeier/svelte-plugin-uses-wrong-typescript-version-reproduction

For me, I only need to open the project folder in VS Code and I get the red underline like in the screenshot above.

Expected behavior

I expect the extension to use the Typescript version I configured in VS Code (especially if I set it to use the version from my node_modules).

[danieldiekmeier]

Okay, I understand! I hope that it will become unnecessary very soon, when either Zod or Typescript can figure out their differences.

I think I can’t really go back to a previous version, because of the other error I recently bumped into.

But I figured out that if I do

cd ~/.vscode/extensions/svelte.svelte-vscode-105.1.0
npm i -D typescript@4.2
npm i # before i did this, lodash was missing?

the extension somehow still works and now behaves correctly. This is probably not a great idea and if it breaks, it’s my own fault, but at least I can now continue to work for the time being 😄

[jrylan]

@dummdidumm, you’re right it does sound more like #905. I’m sorry for hijacking this issue.

And you do understand correctly. Right now, if you’re building a project using Deno + Svelte, and are using the Svelte VS Code extension, you will get TS errors (TS error 2691) for imports that include a “.ts” extension in the import source path.

So Deno + Svelte users are forced to do the following:

1. Omit the use of .ts extensions in the import sources within Svelte files, which is opposite of Deno, which requires full paths.
2. Wire up some custom logic or a Svelte preprocessor to add in the .ts extension to import sources that don’t have a file extension… this is risky to do from the perspective of a library because the lib would have to actually try to resolve the modules every single time in order to figure out if it’s truly a TS file or not. You couldn’t just go off of whether or not there was a period in the filename, someone could be importing import * as foo from "./src/foo.bar"; when the actual filename is ./src/foo.bar.ts.

Just a small note here about Svelte imports such as svelte/internal: Deno can easily handle those via the use of an import_map.json file for dependencies.

So the most future-proof solution is a specific opt-in configuration for people that use Deno or a custom Node.js loader that wish to suppress the TS errors. The code I provided above not only allows a user to specify an import source with a .ts extension intact, it also automatically patches up the autocomplete for an import/export source in VS Code to reference the full file name with the .ts extension.

Like I said above, when using the Deno for VS Code, .ts extensions are allowed with the TS error suppressed but only within .ts and .tsx files.

I know it seems like an edge-case, but people REALLY want to be able to use TS with full paths, and the TS team is not budging on it. It’s silly, because people are already doing it, and the TS team won’t implement because they want to avoid confusion about not changing import/export source paths at compile time… in the case of Deno and Node.js custom loaders, the TS compiler is never even touched. Many people use SWC in Deno or Babel in Node.js, they are treating TS as only a type checker, not a compiler.

Take a look at these TS issues for how popular of a request this is, it’s not exclusive to Deno: https://github.com/microsoft/TypeScript/issues/27481 https://github.com/microsoft/TypeScript/issues/37582

If you’re open to a PR to add a configuration option, I can submit one. I would want to name the option something generic, not specific to Deno, since it is applicable to people using custom Node.js loaders as well. Something like:

Enable literal TypeScript module resolution “When enabled, this option allows you to include the .ts file extension in your import and export sources within a Svelte component. This is useful for custom Node.js loaders and other JS runtimes which require complete source paths with file extensions.”

---

** EDIT (hours later) ** I’ve been digging through the Svelte VS Code Extension, I’ve figured out the .ts extension patching must happen within the Svelte language server, specifically at the source file svelte-language-server/dist/src/plugins/typescript/module-loader.ts.

If I patch, rebuild, and then reload VS Code, everything works. What I’m not quite sure of yet is if any options from the VS Code extension are passed to the language server at all in order to make the functionality opt-in.