Consistency between LSP JS Doc checks and npm run check

[skiss9]

Hi,

I'm setting up dev environments for a small team, and trying to setup a solid workflow for JS doc type checking.

When I install dependencies such as threeJS or lodash, I've noticed that both npm run check and tsc -p jsconfig.json require npm i @types/lodash to clear all diagnostic errors, while LSP-based checks from nvim (ts_ls), Sublime LSP typescript and VSCode don't require that manual type install.

This results in inconsistent diagnostics between IDE LSPs and npm run check, and also manifests as inconsistencies between checks for code written in JS files vs in svelte components when using VSCode with svelte LSP and typescript LSP extensions installed.

Repro steps

• Create a new svelte kit app using the sv CLI
• Pick JS Doc, eslint, prettier, vitest
• Install lodash with npm
• Add a lodash import into a JS file (not svelte component)
• Run npm run check
• Open the app with VSCode

Observed behavior

VSCode shows no errors, while npm run check shows an error
Also, in VSCode, importing lodash in a svelte component shows an error while importing lodash in a JS file shows no errors

Expected behavior

A way to get consistent diagnostics between the IDE LSPs and npm run check, whether in svelte components or js files.

I also created this stackblitz app that shows a similar version of the problem. If you run npm run check in it, it will show an error. The same code in VSCode in a JS file would show no error.
https://stackblitz.com/edit/sveltejs-kit-template-default-fgqgad?file=src%2Froutes%2F%2Bpage.svelte

Same code in svelte component vs JS file (VSCode with svelte LSP and typescript LSP extensions installed):

[piktaun]

Hi Stephane, The issue you're facing is a common inconsistency between IDE LSPs and TypeScript diagnostics when dealing with type definitions, especially in JS Doc setups. Here's how you can address it and ensure consistent diagnostics across your tools: 1. **Install Type Definitions Explicitly** Ensure you install type definitions explicitly for packages like `lodash`: ``` npm install --save-dev @types/lodash ``` 2. **Configure `jsconfig.json` or `tsconfig.json` Correctly** Update your `jsconfig.json` or `tsconfig.json` to include `typeRoots`: ```json { "compilerOptions": { "typeRoots": ***@***.***"], "checkJs": true }, "include": ["src/**/*"] } ``` 3. **Align LSP and TypeScript Configuration** Ensure that your IDE (VSCode, Sublime, etc.) uses the same TypeScript version and configuration. In VSCode, you can set this in your workspace settings: ```json { "typescript.tsdk": "node_modules/typescript/lib" } ``` 4. **Svelte-Specific Adjustments** For Svelte components, ensure the `svelte-check` tool is properly configured: - Install `svelte-check` and ***@***.***/language-tools`: ``` npm install --save-dev svelte-check @sveltejs/language-tools ``` - Add a `svelte.config.js` if missing: ```js import { vitePreprocess } from ***@***.***/kit/vite'; export default { preprocess: vitePreprocess(), }; ``` 5. **Run Consistent Checks** Use the same toolchain for diagnostics to avoid discrepancies: - Add a script in `package.json` to include both `tsc` and `svelte-check`: ```json "scripts": { "check": "tsc --project jsconfig.json && svelte-check" } ``` 6. **Verify LSP Configurations** For LSP tools, ensure both the TypeScript and Svelte extensions are configured to use the same type definitions. For VSCode, ensure ***@***.***` packages are globally recognized: ```json { "typescript.preferences.importModuleSpecifier": "relative", "svelte.language-server.runtime": "node" } ``` 7. **Reproduce with Debugging** To debug issues in `npm run check`, run: ``` npx tsc --traceResolution ``` This helps you see which type definitions are being resolved. Expected Outcome: - Consistent diagnostics across all environments (`npm run check`, IDE LSPs, Svelte components, and JS files). - No errors for valid imports in both JS files and Svelte components. Let me know if you need further assistance! Best regards, Vladislav Suvorov

[skiss9]

Thanks for the detailed answer, lots of good information in there. Some parts got obfuscated around AT characters because they look like emails I guess, would you mind letting me know what these were?