WebStorm has two sources of errors for a .js file. Its own JavaScript engine reads JSDoc and runs the IDE's inspections, and TypeScript's language service, which runs the same checker as tsc, adds TypeScript's errors where the TypeScript settings and your project config bring JavaScript into it. The first is not TypeScript's checker, so it can flag different things than npm run lint.
Per WebStorm's documentation, the TypeScript settings default to the typescript package in your project's node_modules, which is the version your lint script runs, and a Show project errors option lists errors from files you have not opened.
At a glance
| Editor | JetBrains WebStorm |
|---|---|
| What to install | Built in |
| What checks the code | WebStorm's own JavaScript engine, plus TypeScript's language service where the TypeScript settings turn it on |
| Where its TypeScript comes from | The project's node_modules/typescript by default; a copy bundled with the IDE, or one you select, in the TypeScript settings |
| Reads | jsconfig.json, tsconfig.json |
| How this page was checked | Not run in WebStorm for this page. The settings are from the WebStorm documentation linked below; what the TypeScript language service reports is the same service the site's tests run. |
Which TypeScript it runs
Settings | Languages & Frameworks | TypeScript has a TypeScript field. By default it points at the project's node_modules/typescript; Bundled uses the copy shipped with the IDE, and Select picks another package. Keep the project's copy so the editor and tsc are the same version: a newer or older TypeScript can add or drop errors.
The language service and JavaScript files
The same page has a TypeScript language service checkbox, on by default, and per the documentation the service's suggestions reach JavaScript files once allowJs is set in jsconfig.json or tsconfig.json. A jsconfig.json sets allowJs by default, but writing "allowJs": true and "checkJs": true explicitly does no harm and makes the intent visible to tools that read the file literally.
The documentation describes the TypeScript settings in terms of tsconfig.json (its Options field applies "when no tsconfig.json is found"). If the editor does not show tsc's errors in .js files, check which config the file belongs to before changing anything else.
Errors in files you have not opened
With Show project errors selected (the default), the language service checks the whole project and lists the results on the Project Errors tab of the Problems tool window. Clear it to check only open files, which the documentation suggests for performance in large projects.
For the same output CI sees, run the lint script itself: WebStorm runs package.json scripts from the editor gutter and the npm tool window.
{
"scripts": {
"lint": "tsc -p jsconfig.json"
}
}What differs from tsc
WebStorm's own inspections (unused code, possible bugs, style) are not TypeScript diagnostics and have no TS code; tsc will never report them. Show suggestions adds TypeScript's suggestions, such as names marked @deprecated and parameters whose type could be inferred from usage, which tsc does not print either.
Make sure it matches tsc
Open a file that npm run lint reports an error for and look for the same TS code in the editor. If it is missing, check the TypeScript version field first, then that the file is covered by the include of the config you lint with.
Gotchas
- An error with no
TScode in its tooltip comes from a WebStorm inspection, not from TypeScript, and has no page in this site's error reference. - The Enable service-powered type engine option (off by default) makes the IDE use TypeScript's checker for the types it shows; it is about type information in the IDE, not about which errors are reported.
Sources
- TypeScript settings · WebStorm documentation
- TypeScript · WebStorm documentation
- npm, pnpm, and Yarn: Run scripts from package.json · WebStorm documentation
Last reviewed 20 October 2026.