language-tools
language-tools copied to clipboard
sveltejs
LSP is slow
Is it me or this LSP is kinda slow? I'm used to instant response from Gopls and at least for small projects, the language as complex as Haskell, has quite fast response times. But Svelte seems to require you to wait for few seconds before seeing errors, etc. What can we do to make it faster if possible at all?
Can you provide a reproduction repository where you see the slowness? Else there's not much we can investigate here.
Is it me or this LSP is kinda slow? I'm used to instant response from Gopls and at least for small projects, the language as complex as Haskell, has quite fast response times. But Svelte seems to require you to wait for few seconds before seeing errors, etc. What can we do to make it faster if possible at all?
It is indeed slow for me as well. I literally turned it off because I have to wait for autocompletion for like 3 seconds or so and the project is not even complex. Also I am not down on any system resources and it's pretty modern setup.
If you have a reproduction that would be great. Is this a Svelte 5 project?
If you have a reproduction that would be great. Is this a Svelte 5 project?
Svelte 5, yes. I'm not even sure about reproduction, it works the same on any Svelte 5 project. Compared to typescript and go, lsp is incredibly unresponsive
Please provide a reproduction repository (it's fine if it's just your whole open source repository, if it is one) with steps how to reproduce the slowness
@dummdidumm
Thank you for supporting us! I've encountered the same problem with slow autocompletion.
I've probably managed to reproduce the problem, so I'll send you a minimal repository and a reproduction video. In my environment, it seems that installing the date-fns library causes the slow autocompletion problem.
Please check it out!
https://github.com/noughts/svelte-ls-demo
https://github.com/user-attachments/assets/3a23d49e-53a4-44ef-b868-281adadfc85f
@noughts This problem is probably similar to #2244. The libary has a huge package.json with nearly 1000 entries in its export map. But I can't reproduce the performance issue with the last version.
Both the caching and parser error issues I mentioned in that issue should be resolved now. You mentioned it'll get faster after the first completion. So at least you should be using a version with the auto-import cache. Can you check if you have the latest version of the extension and if you're using Svelte 5.16+?
@jasonlyu123 Thank you for your support!
It certainly looks like this issue is similar to #2244.
I installed svelte-google-materialdesign-icons as a test in my environment and had the same problem.
I made sure I installed and tested the latest versions of Svelte / SvelteKit / Svelte For VS Code Extension all installed. The specific version numbers are as follows:
Svelte: 5.19.6
SvelteKit: 2.16.1
Svelte For VS Code Extension: 109.5.2
https://github.com/noughts/svelte-ls-demo/blob/main/package-lock.json#L1327
Either way, I'm glad to know that the problem is caused by libraries with large amounts of exports in their package.json.
I can avoid the degradation of the developer experience by avoiding such libraries.
Thank you for your support!
You also don't have the svelte.language-server.ls-path config right? If so, you can check if the custom language server installation is the latest version.
Now since there is auto-import cache and the parser error problem is resolved. The performance issue with a large export map in package.json is mostly a TypeScript issue. You could try if the problem also exists in a ts file in your environment. If this is the case, you can consider opening an issue in TypeScript. I didn't do it when we were checking out #2244 because I didn't understand why is it necessary, and the problematic libary was mostly a svelte-specific icon libary but date-fns isn't the case.
Edit: oops I accidentally clicked the wrong button 😆
I have the same problem too, it's very slow. as a test project with just drizzle and libsql as big library and other standard stuff like prettier and eslint it must be much faster. Svelte 5 itself now is a good framework and I like it but its ecosystem and tooling are still week
https://github.com/user-attachments/assets/cdf9c52e-0eaf-47be-9183-4b72ed5f2ba6
my Package.json: { "name": "ebook", "private": true, "version": "0.0.1", "type": "module", "scripts": { "dev": "vite dev", "build": "vite build", "preview": "vite preview", "prepare": "svelte-kit sync || echo ''", "format": "prettier --write .", "lint": "prettier --check . && eslint .", "db:push": "drizzle-kit push", "db:migrate": "drizzle-kit migrate", "db:studio": "drizzle-kit studio" }, "devDependencies": { "@eslint/compat": "^1.2.5", "@eslint/js": "^9.18.0", "@sveltejs/adapter-auto": "^4.0.0", "@sveltejs/kit": "^2.16.0", "@sveltejs/vite-plugin-svelte": "^5.0.0", "drizzle-kit": "^0.30.2", "eslint": "^9.18.0", "eslint-config-prettier": "^10.0.1", "eslint-plugin-svelte": "^2.46.1", "globals": "^15.14.0", "prettier": "^3.4.2", "prettier-plugin-svelte": "^3.3.3", "svelte": "^5.0.0", "vite": "^6.0.0" }, "dependencies": { "@libsql/client": "^0.14.0", "drizzle-orm": "^0.38.4" }, "packageManager": "[email protected]+sha512.b2dc20e2fc72b3e18848459b37359a32064663e5627a51e4c74b2c29dd8e8e0491483c3abb40789cfd578bf362fb6ba8261b05f0387d76792ed6e23ea3b1b6a0" }
@itskazemk I can't reproduce the issue with just the package.json. Are you using the latest version of the extension and are you using Svelte 5.16+? Also, the delay should only appear the first time you try to auto-import in a file. If this wasn't the case, please provide a reproduction repository.
SvelteKit uses ESM module system so the module resolution config in the jsconfig/tsconfig is set to module resolution bundler or NodeNext by default. With the bundler and NodeNext config, TypeScript needs to do a lot more stuff up front to filter out imports that are blocked by the export map. So it is pretty normal to have a slightly slower start-up time compared to projects with module resolution: node. But it should work a lot faster after the first auto-import where the expensive analysis is cached.
The problem should also exist in a TypeScript file. In older svelte versions, There is the parser-error state issue that might cause TypeScript to load more auto-import so it has a longer delay. But it should happen less frequently with Svelte 5.16+.
Any update on this export map issue? Several popular libraries use large export maps. I'm stuck with this issue for a large codebase that I can't migrate, and it seems like it's getting worse as I add more code. Saving a file that imports a package with a large export map often takes up to 10 seconds to save with the 'Svelte for VsCode' plugin window hanging. Svelte files without large export map packages imported, the plugin executes almost instantly. It's effectively making it impossible to use svelte(for me).
Some of the libraries are: hono, date-fns
Can I create a PR for this?
The export map issue needs more than 3000-5000 conditions to happen. I am not aware that there are a lot of libraries that do this "weird" thing. Also, the problem is with auto-import. It doesn't seem to match your description. But you're welcome to debug and contribute to what might be the problem with your specific case. The export map issue is on the upstream TypeScript side, so if it turns out to be the issue, you should open an issue on TypeScript's repo. Preferably with a reproduction within a ts file.