{
  "editors": [
    {
      "id": "vs-code",
      "slug": "vs-code",
      "title": "VS Code",
      "editor": "Visual Studio Code",
      "typescriptSource": "A copy bundled with the editor, or the project's `typescript` package when you pick **Use Workspace Version**",
      "languageServer": "TypeScript's own server (`tsserver`), started by VS Code's built-in JavaScript and TypeScript support",
      "setup": "No extension needed",
      "checkedHere": "Not run in VS Code for this page. The settings and commands are from the VS Code documentation linked below; what the editor reports, the faded and struck-through suggestions included, comes from TypeScript's language service, which the site's tests run.",
      "summary": "Set up VS Code for type-checked JavaScript: how it reads jsconfig.json, using the project's TypeScript version, and listing errors in files you have not opened.",
      "intro": [
        "VS Code's JavaScript support is TypeScript's language service, so the hovers, completions and red squiggles in a `.js` file come from the same checker that `tsc` runs. It reads the nearest `jsconfig.json` or `tsconfig.json` and needs no extension for any of this.",
        "Two changes make the editor agree with `npm run lint`: use the project's TypeScript version instead of the copy bundled with the editor, and run `tsc` as a task when you want errors from files you have not opened."
      ],
      "examples": [],
      "sections": [
        {
          "id": "jsconfig",
          "heading": "It finds your jsconfig.json",
          "body": [
            "Open the folder that contains `jsconfig.json` (or a folder above it). Every `.js` file the config includes becomes part of one project, so types flow between files and the editor checks them with your compiler options. The **Go to Project Configuration** command in the Command Palette opens the config file the current file belongs to, which is the quickest way to check which one is in use."
          ]
        },
        {
          "id": "workspace-version",
          "heading": "Use the project's TypeScript version",
          "body": [
            "VS Code ships with its own copy of TypeScript, which can be newer or older than the `typescript` package your `lint` script runs. It finds the copy in your project's `node_modules` by itself: open a JavaScript or TypeScript file, click the TypeScript version number in the status bar (or run **TypeScript: Select TypeScript Version** from the Command Palette) and choose **Use Workspace Version**.",
            "To name the copy explicitly, set `js/ts.tsdk.path` to its `lib` folder in the workspace settings. Older VS Code releases call this setting `typescript.tsdk`."
          ],
          "snippets": [
            {
              "file": ".vscode/settings.json",
              "lang": "jsonc",
              "code": "{\n  // the TypeScript in node_modules, the one npm run lint uses\n  \"js/ts.tsdk.path\": \"node_modules/typescript/lib\"\n}"
            }
          ]
        },
        {
          "id": "loose-files",
          "heading": "Check files that belong to no project",
          "body": [
            "For a one-off script with no `jsconfig.json` around it, either make `// @ts-check` its first line, or turn checking on for every loose JavaScript file in your user settings:"
          ],
          "snippets": [
            {
              "file": "settings.json",
              "lang": "jsonc",
              "code": "{\n  \"js/ts.implicitProjectConfig.checkJs\": true\n}"
            }
          ]
        },
        {
          "id": "all-errors",
          "heading": "List errors in files you have not opened",
          "body": [
            "The editor reports errors for the files you have open. To see every error in the project in the Problems panel, run `tsc` as a task with the `$tsc` problem matcher, which reads tsc's output. `--pretty false` keeps the output in the plain one-line format."
          ],
          "snippets": [
            {
              "file": ".vscode/tasks.json",
              "lang": "jsonc",
              "code": "{\n  \"version\": \"2.0.0\",\n  \"tasks\": [\n    {\n      \"label\": \"Check types\",\n      \"type\": \"shell\",\n      \"command\": \"npx tsc -p jsconfig.json --pretty false\",\n      \"problemMatcher\": \"$tsc\"\n    }\n  ]\n}"
            }
          ]
        },
        {
          "id": "differs",
          "heading": "What differs from tsc",
          "body": [
            "The editor reports errors for the files you open, plus TypeScript's suggestions, which `tsc` never prints: names declared but never read are faded when `noUnusedLocals` is off, names marked `@deprecated` are struck through, and some lines get a hint with a quick fix (the light bulb). None of these fail `npm run lint`."
          ]
        },
        {
          "id": "match",
          "heading": "Make sure it matches tsc",
          "body": [
            "After installing an `@types` package or editing `jsconfig.json`, the editor normally picks up the change by itself. If it does not, run **TypeScript: Restart TS Server**. If it still disagrees with `npm run lint`, compare the version number in the status bar with the output of `npx tsc -v`, and run **Go to Project Configuration** to see which config file the current file belongs to."
          ]
        }
      ],
      "gotchas": [
        "The bundled and the workspace TypeScript can disagree about new syntax and new checks. If CI runs `tsc`, use the workspace version so you see the same errors before you push.",
        "With a `jsconfig.json` that does not set `checkJs`, `.js` files get completions and hovers but no type errors, except in files that start with `// @ts-check`."
      ],
      "related": [
        "config/check-js",
        "start/node-esm",
        "tags/type",
        "tags/deprecated",
        "errors/ts6133"
      ],
      "sources": [
        {
          "title": "JavaScript in Visual Studio Code",
          "url": "https://code.visualstudio.com/docs/languages/javascript",
          "publisher": "Visual Studio Code docs"
        },
        {
          "title": "Working with JavaScript (type checking)",
          "url": "https://code.visualstudio.com/docs/nodejs/working-with-javascript",
          "publisher": "Visual Studio Code docs"
        },
        {
          "title": "jsconfig.json",
          "url": "https://code.visualstudio.com/docs/languages/jsconfig",
          "publisher": "Visual Studio Code docs"
        },
        {
          "title": "Transpiling TypeScript (the workspace version, tasks)",
          "url": "https://code.visualstudio.com/docs/typescript/typescript-transpiling",
          "publisher": "Visual Studio Code docs"
        }
      ],
      "updated": "2026-10-20"
    },
    {
      "id": "webstorm",
      "slug": "webstorm",
      "title": "WebStorm",
      "editor": "JetBrains WebStorm",
      "typescriptSource": "The project's `node_modules/typescript` by default; a copy bundled with the IDE, or one you select, in the TypeScript settings",
      "languageServer": "WebStorm's own JavaScript engine, plus TypeScript's language service where the TypeScript settings turn it on",
      "setup": "Built in",
      "checkedHere": "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.",
      "summary": "Type-checked JavaScript in WebStorm: the TypeScript version setting, the language service, project-wide errors, and how to confirm the IDE agrees with tsc.",
      "intro": [
        "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."
      ],
      "examples": [],
      "sections": [
        {
          "id": "typescript-version",
          "heading": "Which TypeScript it runs",
          "body": [
            "**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."
          ]
        },
        {
          "id": "language-service",
          "heading": "The language service and JavaScript files",
          "body": [
            "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."
          ]
        },
        {
          "id": "project-errors",
          "heading": "Errors in files you have not opened",
          "body": [
            "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."
          ],
          "snippets": [
            {
              "file": "package.json",
              "lang": "json",
              "code": "{\n  \"scripts\": {\n    \"lint\": \"tsc -p jsconfig.json\"\n  }\n}"
            }
          ]
        },
        {
          "id": "differs",
          "heading": "What differs from tsc",
          "body": [
            "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."
          ]
        },
        {
          "id": "match",
          "heading": "Make sure it matches tsc",
          "body": [
            "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 `TS` code 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."
      ],
      "related": [
        "config/check-js",
        "config/allow-js",
        "start/node-esm",
        "editors/vs-code",
        "errors/ts7006"
      ],
      "sources": [
        {
          "title": "TypeScript settings",
          "url": "https://www.jetbrains.com/help/webstorm/settings-languages-typescript.html",
          "publisher": "WebStorm documentation"
        },
        {
          "title": "TypeScript",
          "url": "https://www.jetbrains.com/help/webstorm/typescript-support.html",
          "publisher": "WebStorm documentation"
        },
        {
          "title": "npm, pnpm, and Yarn: Run scripts from package.json",
          "url": "https://www.jetbrains.com/help/webstorm/npm.html",
          "publisher": "WebStorm documentation"
        }
      ],
      "updated": "2026-10-20"
    },
    {
      "id": "neovim",
      "slug": "neovim",
      "title": "Neovim",
      "editor": "Neovim",
      "typescriptSource": "Decided by the language server: `typescript-language-server` can use the workspace's TypeScript; `vtsls` uses its bundled copy unless told to use the workspace's",
      "languageServer": "Neovim's built-in LSP client talking to `typescript-language-server` (`ts_ls`) or `vtsls`, both of which run TypeScript's own server",
      "setup": "nvim-lspconfig + a language server",
      "checkedHere": "Not run in Neovim for this page. The configuration is from Neovim's documentation (`:help lsp`) and the nvim-lspconfig `ts_ls` and `vtsls` configs linked below; what the servers report comes from TypeScript's language service, which the site's tests run.",
      "summary": "Set up Neovim for type-checked JavaScript: vim.lsp.enable with ts_ls or vtsls, making the server use your project's TypeScript, and checking it agrees with tsc.",
      "intro": [
        "Neovim has an LSP client built in. Since Neovim 0.11, `vim.lsp.config()` and `vim.lsp.enable()` set up a server in a few lines, and the nvim-lspconfig plugin supplies ready-made configs named `ts_ls` (for `typescript-language-server`) and `vtsls`. Both servers wrap TypeScript's own `tsserver`, so the errors in a `.js` file are the ones `tsc` reports, given the same TypeScript and the same `jsconfig.json`.",
        "Install one server globally with npm, enable it, and the rest comes from your project: `tsserver` finds the nearest `jsconfig.json` above each file, so `checkJs`, `strict` and the other options apply as they do on the command line."
      ],
      "examples": [],
      "sections": [
        {
          "id": "enable",
          "heading": "Enable a TypeScript language server",
          "body": [
            "With nvim-lspconfig installed (it provides the server definitions), one line in `init.lua` starts `ts_ls` for JavaScript and TypeScript buffers. Install the server first: nvim-lspconfig's `ts_ls` config gives `npm install -g typescript typescript-language-server`, and its `vtsls` config gives `npm install -g @vtsls/language-server`."
          ],
          "snippets": [
            {
              "file": "init.lua",
              "lang": "lua",
              "code": "-- Neovim 0.11+, with nvim-lspconfig installed for its server definitions\nvim.lsp.enable('ts_ls')"
            }
          ]
        },
        {
          "id": "typescript-version",
          "heading": "Use the project's TypeScript",
          "body": [
            "The version matters because each TypeScript release adds and changes checks; the editor should run the version in your project's `node_modules`, which is what `npm run lint` runs. `typescript-language-server` reports where its TypeScript came from (the workspace, a configured `tsserver.path`, or its bundled copy), and the `ts_ls` config starts a project-local `typescript-language-server` from `node_modules/.bin` when there is one.",
            "`vtsls` uses the TypeScript it bundles unless you set `vtsls.autoUseWorkspaceTsdk`, per its README:"
          ],
          "snippets": [
            {
              "file": "init.lua",
              "lang": "lua",
              "code": "vim.lsp.config('vtsls', {\n  settings = {\n    -- use node_modules/typescript instead of the copy vtsls ships with\n    vtsls = { autoUseWorkspaceTsdk = true },\n  },\n})\nvim.lsp.enable('vtsls')"
            }
          ]
        },
        {
          "id": "jsconfig",
          "heading": "How the config is found",
          "body": [
            "nvim-lspconfig decides the workspace root from lockfiles and `.git`, not from `jsconfig.json`. That is only the LSP workspace: inside it, TypeScript's server still looks for the nearest `jsconfig.json` or `tsconfig.json` above each file, so a project with several configs is checked with the right one per file."
          ]
        },
        {
          "id": "differs",
          "heading": "What differs from tsc",
          "body": [
            "Neovim shows the diagnostics for the buffers you open, through `vim.diagnostic` (configure how with `vim.diagnostic.config()`). Servers also pass on TypeScript's suggestions, such as unused names when `noUnusedLocals` is off and names marked `@deprecated`; `tsc` never prints those. Quick fixes come through code actions (the default `gra` mapping)."
          ]
        },
        {
          "id": "match",
          "heading": "Make sure it matches tsc",
          "body": [
            "Run `npm run lint` (or `npx tsc -p jsconfig.json --pretty false`) in a terminal, open one of the files it lists, and compare the codes. Errors in files you have not opened appear only in that output."
          ]
        }
      ],
      "gotchas": [
        "`ts_ls` and `vtsls` are alternatives; enabling both runs two servers and shows each error twice.",
        "The nvim-lspconfig `ts_ls` notes say it needs a TypeScript version below 7 for now."
      ],
      "related": [
        "editors/vim-ale",
        "editors/vs-code",
        "config/check-js",
        "start/node-esm"
      ],
      "sources": [
        {
          "title": "LSP (:help lsp)",
          "url": "https://neovim.io/doc/user/lsp/",
          "publisher": "Neovim documentation"
        },
        {
          "title": "nvim-lspconfig: lsp/ts_ls.lua",
          "url": "https://github.com/neovim/nvim-lspconfig/blob/master/lsp/ts_ls.lua",
          "publisher": "nvim-lspconfig on GitHub"
        },
        {
          "title": "nvim-lspconfig: lsp/vtsls.lua",
          "url": "https://github.com/neovim/nvim-lspconfig/blob/master/lsp/vtsls.lua",
          "publisher": "nvim-lspconfig on GitHub"
        },
        {
          "title": "typescript-language-server",
          "url": "https://github.com/typescript-language-server/typescript-language-server",
          "publisher": "typescript-language-server on GitHub"
        },
        {
          "title": "vtsls",
          "url": "https://github.com/yioneko/vtsls",
          "publisher": "vtsls on GitHub"
        }
      ],
      "updated": "2026-10-20"
    },
    {
      "id": "vim-ale",
      "slug": "vim-ale",
      "title": "Vim with ALE",
      "editor": "Vim with ALE",
      "typescriptSource": "The `tsserver` in the project's `node_modules/.bin`, which ALE looks for first; a global `tsserver` otherwise",
      "languageServer": "ALE's `tsserver` linter, which talks to TypeScript's own server directly",
      "setup": "ALE plugin",
      "checkedHere": "Not run in Vim for this page. The settings are from ALE's documentation and source linked below (its help file, `ale-typescript`, and the `tsserver` linter and handler); what tsserver reports comes from TypeScript's language service, which the site's tests run.",
      "summary": "Set up Vim with ALE for type-checked JavaScript: the tsserver linter, the project root ALE needs, the project's TypeScript, and checking it agrees with tsc.",
      "intro": [
        "ALE (Asynchronous Lint Engine) checks the buffers you edit and can talk to TypeScript's server, `tsserver`, as a JavaScript linter named `tsserver`. VS Code uses the same server, and it runs the same checker as `tsc`, so its errors in a `.js` file are tsc's errors.",
        "One detail decides whether it runs at all in a JavaScript project. Per ALE's source, its `tsserver` linter finds the project root by looking for the nearest `tsconfig.json`, and its help says an LSP linter with no project root does not run. A project with only a `jsconfig.json` therefore needs the root set through `g:ale_root`."
      ],
      "examples": [],
      "sections": [
        {
          "id": "enable",
          "heading": "Turn on the tsserver linter and give it a root",
          "body": [
            "List `tsserver` among the JavaScript linters, and map it to the folder that holds `jsconfig.json`. `g:ale_root` takes a dictionary from linter name to a path or a function of the buffer number; the function below uses ALE's own helper for finding the nearest file."
          ],
          "snippets": [
            {
              "file": "~/.vim/vimrc",
              "lang": "vim",
              "code": "\" run TypeScript's server on JavaScript files, next to ESLint if you use it\nlet g:ale_linters = {'javascript': ['tsserver', 'eslint']}\n\n\" ALE looks for tsconfig.json to find the project root; point it at jsconfig.json\nlet g:ale_root = {\n\\   'tsserver': {buffer -> fnamemodify(ale#path#FindNearestFile(buffer, 'jsconfig.json'), ':h')},\n\\}"
            }
          ]
        },
        {
          "id": "typescript-version",
          "heading": "Which TypeScript it runs",
          "body": [
            "ALE looks for `node_modules/.bin/tsserver` above the file and uses it, falling back to a `tsserver` on your `PATH` (the `g:ale_javascript_tsserver_executable` setting). Keep `typescript` in the project's dev dependencies so that the local copy exists and matches the version `npm run lint` runs; `g:ale_javascript_tsserver_use_global` would make ALE skip it."
          ]
        },
        {
          "id": "differs",
          "heading": "What differs from tsc",
          "body": [
            "ALE checks buffers, so errors in files you have not opened are not listed. It shows problems with signs, in the location list and, if you enable it, as virtual text; `:ALEDetail` prints the full message, including the indented lines of a long TypeScript error. `:ALEGoToDefinition` and `:ALEHover` use the same server, and completion works when `g:ale_completion_enabled` is set before ALE loads."
          ]
        },
        {
          "id": "match",
          "heading": "Make sure it matches tsc",
          "body": [
            "Run `npm run lint` (or `npx tsc -p jsconfig.json --pretty false`) in a terminal, open a file it reports, and compare. `:ALEInfo` shows which linters ran for the buffer and the command ALE used, which answers most \"why is nothing reported\" questions."
          ]
        }
      ],
      "gotchas": [
        "Adding a `tsconfig.json` that only says `\"extends\": \"./jsconfig.json\"` is the other way to give ALE a root; TypeScript's server then reads that file for those folders, so keep it a pure `extends`. Setting `g:ale_root` leaves the project untouched.",
        "Per ALE's help, an LSP linter without a project root does not run, so a project with only a `jsconfig.json` and no `g:ale_root` gets no TypeScript errors from ALE at all, which looks like a clean file."
      ],
      "related": [
        "editors/neovim",
        "config/check-js",
        "start/node-esm"
      ],
      "sources": [
        {
          "title": "ALE help (doc/ale.txt): g:ale_root, g:ale_linters",
          "url": "https://github.com/dense-analysis/ale/blob/master/doc/ale.txt",
          "publisher": "ALE on GitHub"
        },
        {
          "title": "ALE: the JavaScript tsserver linter",
          "url": "https://github.com/dense-analysis/ale/blob/master/ale_linters/javascript/tsserver.vim",
          "publisher": "ALE on GitHub"
        },
        {
          "title": "ALE: tsserver project root handler",
          "url": "https://github.com/dense-analysis/ale/blob/master/autoload/ale/handlers/tsserver.vim",
          "publisher": "ALE on GitHub"
        },
        {
          "title": "ALE help (doc/ale-typescript.txt)",
          "url": "https://github.com/dense-analysis/ale/blob/master/doc/ale-typescript.txt",
          "publisher": "ALE on GitHub"
        }
      ],
      "updated": "2026-10-20"
    },
    {
      "id": "zed",
      "slug": "zed",
      "title": "Zed",
      "editor": "Zed",
      "typescriptSource": "The default server, `vtsls`, uses the TypeScript it bundles unless its `autoUseWorkspaceTsdk` setting is on",
      "languageServer": "`vtsls` by default (a language server built on VS Code's TypeScript support); `typescript-language-server` as the alternative",
      "setup": "Built in",
      "checkedHere": "Not run in Zed for this page. The settings are from Zed's JavaScript and TypeScript documentation and the vtsls README linked below; what the server reports comes from TypeScript's language service, which the site's tests run.",
      "summary": "Set up Zed for type-checked JavaScript: the vtsls server it uses by default, making it run your project's TypeScript, and checking it agrees with tsc.",
      "intro": [
        "Zed supports JavaScript out of the box, and per its documentation it uses `vtsls` as the language server for JavaScript and TypeScript, with `typescript-language-server` as the alternative. Both run TypeScript's own server, which reads the nearest `jsconfig.json`, so with `checkJs` on the errors in a `.js` file are tsc's errors.",
        "The setting worth adding is the TypeScript version: per the vtsls README, vtsls runs the TypeScript it bundles by default, which can be newer or older than the one in your project."
      ],
      "examples": [],
      "sections": [
        {
          "id": "typescript-version",
          "heading": "Use the project's TypeScript",
          "body": [
            "Language server settings go under `lsp` in Zed's `settings.json`, keyed by server name, and the server's own settings under `settings`, the same nesting Zed's TypeScript page uses for vtsls's memory limit. vtsls's switch for the workspace TypeScript is `vtsls.autoUseWorkspaceTsdk`:"
          ],
          "snippets": [
            {
              "file": "settings.json",
              "lang": "jsonc",
              "code": "{\n  \"lsp\": {\n    \"vtsls\": {\n      \"settings\": {\n        // run node_modules/typescript, the version npm run lint uses\n        \"vtsls\": { \"autoUseWorkspaceTsdk\": true }\n      }\n    }\n  }\n}"
            }
          ]
        },
        {
          "id": "switch-server",
          "heading": "Switching to typescript-language-server",
          "body": [
            "Zed's documentation shows the `language_servers` list for this: put `typescript-language-server` first and `!vtsls` to turn vtsls off, keeping `...` for the other defaults, in the `languages` section for JavaScript (and for TypeScript and TSX if you use them)."
          ],
          "snippets": [
            {
              "file": "settings.json",
              "lang": "jsonc",
              "code": "{\n  \"languages\": {\n    \"JavaScript\": {\n      \"language_servers\": [\"typescript-language-server\", \"!vtsls\", \"...\"]\n    }\n  }\n}"
            }
          ]
        },
        {
          "id": "differs",
          "heading": "What differs from tsc",
          "body": [
            "Zed shows diagnostics for the files the server has open. TypeScript's suggestions (unused names when `noUnusedLocals` is off, `@deprecated` names) come through the server too, though `tsc` never prints them. Quick fixes appear as code actions."
          ]
        },
        {
          "id": "match",
          "heading": "Make sure it matches tsc",
          "body": [
            "Run `npm run lint` in Zed's terminal, open a file it reports, and compare the codes. A file that shows no errors in Zed but fails `tsc` usually means a different TypeScript version or a file outside the config's `include`."
          ]
        }
      ],
      "gotchas": [
        "Zed's documentation covers JSDoc highlighting but does not describe `jsconfig.json` handling; the server, not Zed, reads it.",
        "The ESLint integration described on Zed's JavaScript page runs through code actions; it is separate from type checking and reports different problems."
      ],
      "related": [
        "editors/vs-code",
        "editors/neovim",
        "config/check-js",
        "start/node-esm"
      ],
      "sources": [
        {
          "title": "JavaScript",
          "url": "https://zed.dev/docs/languages/javascript",
          "publisher": "Zed documentation"
        },
        {
          "title": "TypeScript",
          "url": "https://zed.dev/docs/languages/typescript",
          "publisher": "Zed documentation"
        },
        {
          "title": "vtsls",
          "url": "https://github.com/yioneko/vtsls",
          "publisher": "vtsls on GitHub"
        }
      ],
      "updated": "2026-10-20"
    },
    {
      "id": "sublime-text",
      "slug": "sublime-text",
      "title": "Sublime Text",
      "editor": "Sublime Text",
      "typescriptSource": "Decided by `typescript-language-server`, which LSP-typescript installs and updates itself; it can use the workspace's TypeScript or a `tsserver.path` you set",
      "languageServer": "The LSP package, with the LSP-typescript helper package running `typescript-language-server`",
      "setup": "LSP + LSP-typescript packages",
      "checkedHere": "Not run in Sublime Text for this page. The settings are from the LSP package's documentation and the LSP-typescript README and default settings linked below; what the server reports comes from TypeScript's language service, which the site's tests run.",
      "summary": "Set up Sublime Text for type-checked JavaScript with the LSP and LSP-typescript packages: the server, its settings, and checking it agrees with tsc.",
      "intro": [
        "Sublime Text talks to language servers through the LSP package. The LSP-typescript package adds JavaScript and TypeScript support on top of it by running `typescript-language-server`, which wraps TypeScript's own server, so the errors in a checked `.js` file are tsc's errors.",
        "Install both from Package Control and restart. LSP-typescript installs and updates the server itself (its `server_path` setting is `auto`), so there is nothing to install with npm."
      ],
      "examples": [],
      "sections": [
        {
          "id": "settings",
          "heading": "Settings, and loose files without a jsconfig.json",
          "body": [
            "Open **Preferences: LSP-typescript Settings** from the Command Palette. In a project with a `jsconfig.json`, the server reads `checkJs` and the rest from that file. For JavaScript files outside any project, the package's default settings have `implicitProjectConfiguration.checkJs` set to `false`; set it to `true` to check them too, like VS Code's `js/ts.implicitProjectConfig.checkJs`."
          ],
          "snippets": [
            {
              "file": "LSP-typescript.sublime-settings",
              "lang": "jsonc",
              "code": "{\n  \"settings\": {\n    // check .js files that no jsconfig.json covers\n    \"implicitProjectConfiguration.checkJs\": true\n  }\n}"
            }
          ]
        },
        {
          "id": "typescript-version",
          "heading": "Which TypeScript it runs",
          "body": [
            "The package's `initialization_options` include `tsserver.path`, empty by default. Per the typescript-language-server documentation, the server then uses the workspace's TypeScript when it can find one, and otherwise a fallback or its bundled copy; `tsserver.path` takes the path to a `typescript/lib` directory or its `tsserver.js`. Keeping `typescript` in the project's dev dependencies gives it the same version `npm run lint` runs."
          ]
        },
        {
          "id": "differs",
          "heading": "What differs from tsc",
          "body": [
            "Diagnostics show as underlines and gutter icons in open files; the **Goto Diagnostic** command lists them. TypeScript's suggestions arrive too, though `tsc` never prints them. The server's `diagnostics.ignoredCodes` setting can hide codes in the editor, which then disagrees with `tsc` on purpose: leave it empty unless you also silence those codes in the build."
          ]
        },
        {
          "id": "match",
          "heading": "Make sure it matches tsc",
          "body": [
            "Run `npm run lint` in a terminal (or as a Sublime build system), open a reported file, and compare the codes. If the editor shows nothing for a file `tsc` reports, check that the file is inside the folder you opened: the LSP package filters out diagnostics for files outside the workspace folders."
          ]
        }
      ],
      "gotchas": [
        "In Sublime Text 3 the TypeScript and TSX syntaxes need extra packages; Sublime Text 4 has them built in, per the LSP-typescript README.",
        "For Flow projects the README shows how to narrow the package's `selector` so the server leaves Flow files alone."
      ],
      "related": [
        "editors/vs-code",
        "config/check-js",
        "start/node-esm"
      ],
      "sources": [
        {
          "title": "LSP for Sublime Text",
          "url": "https://lsp.sublimetext.io/",
          "publisher": "LSP documentation"
        },
        {
          "title": "LSP: Features (diagnostics)",
          "url": "https://lsp.sublimetext.io/features/",
          "publisher": "LSP documentation"
        },
        {
          "title": "LSP-typescript",
          "url": "https://github.com/sublimelsp/LSP-typescript",
          "publisher": "sublimelsp on GitHub"
        },
        {
          "title": "typescript-language-server configuration",
          "url": "https://github.com/typescript-language-server/typescript-language-server/blob/master/docs/configuration.md",
          "publisher": "typescript-language-server on GitHub"
        }
      ],
      "updated": "2026-10-20"
    },
    {
      "id": "emacs",
      "slug": "emacs",
      "title": "Emacs",
      "editor": "GNU Emacs",
      "typescriptSource": "Decided by `typescript-language-server`; with lsp-mode, `lsp-clients-typescript-prefer-use-project-ts-server` asks for the project's copy",
      "languageServer": "Eglot (built in since Emacs 29) or lsp-mode, each running `typescript-language-server`",
      "setup": "Eglot (built in) or lsp-mode",
      "checkedHere": "Not run in Emacs for this page. The configuration is from Eglot's source and README and lsp-mode's TypeScript page linked below; what the server reports comes from TypeScript's language service, which the site's tests run.",
      "summary": "Set up Emacs for type-checked JavaScript with Eglot or lsp-mode and typescript-language-server: starting the server, picking its TypeScript, and matching tsc.",
      "intro": [
        "Emacs has two common LSP clients. Eglot has been part of Emacs since version 29, and its default server list runs `typescript-language-server --stdio` for `js-mode`, `js-ts-mode` and the TypeScript modes. lsp-mode is a separate package whose `ts-ls` client runs the same server. Either way TypeScript's own server checks the file, with the nearest `jsconfig.json`, so the errors are tsc's errors.",
        "Install the server with npm (`npm install -g typescript-language-server typescript`, per its README), then start the client in JavaScript buffers."
      ],
      "examples": [],
      "sections": [
        {
          "id": "eglot",
          "heading": "Eglot",
          "body": [
            "`M-x eglot` in a JavaScript buffer starts the server Eglot guesses for the mode. To start it automatically, add `eglot-ensure` to the mode hooks. Eglot passes the server's diagnostics to Flymake, which underlines them in the buffer."
          ],
          "snippets": [
            {
              "file": "init.el",
              "lang": "elisp",
              "code": ";; Start Eglot (built in since Emacs 29) in JavaScript buffers\n(add-hook 'js-mode-hook #'eglot-ensure)\n(add-hook 'js-ts-mode-hook #'eglot-ensure)"
            }
          ]
        },
        {
          "id": "lsp-mode",
          "heading": "lsp-mode, and the project's TypeScript",
          "body": [
            "With lsp-mode, `M-x lsp-install-server RET ts-ls` installs the server. Per its documentation lsp-mode does not prefer the project's `tsserver` by default; set `lsp-clients-typescript-prefer-use-project-ts-server` so the editor runs the same TypeScript version as `npm run lint`."
          ],
          "snippets": [
            {
              "file": "init.el",
              "lang": "elisp",
              "code": ";; lsp-mode: use node_modules/typescript, the version npm run lint uses\n(setq lsp-clients-typescript-prefer-use-project-ts-server t)\n(add-hook 'js-mode-hook #'lsp-deferred)"
            }
          ]
        },
        {
          "id": "differs",
          "heading": "What differs from tsc",
          "body": [
            "Diagnostics are reported for the buffers the server has open. Eglot also shows the diagnostic under point through ElDoc. TypeScript's suggestions (unused names with `noUnusedLocals` off, `@deprecated` names) come through as well; `tsc` never prints them."
          ]
        },
        {
          "id": "match",
          "heading": "Make sure it matches tsc",
          "body": [
            "`M-x compile` with `npx tsc -p jsconfig.json --pretty false` runs the same check as CI in a compilation buffer. Open a file it reports and compare the codes with what Flymake shows."
          ]
        }
      ],
      "gotchas": [
        "When Eglot manages a buffer it turns off the other Flymake backends, per its README; `eglot-stay-out-of` changes that if you also run ESLint through Flymake.",
        "Recent development versions of Eglot try another program before `typescript-language-server` for these modes; `eglot-server-programs` shows what your version uses."
      ],
      "related": [
        "editors/neovim",
        "editors/vs-code",
        "config/check-js",
        "start/node-esm"
      ],
      "sources": [
        {
          "title": "Eglot README",
          "url": "https://github.com/joaotavora/eglot",
          "publisher": "Eglot on GitHub"
        },
        {
          "title": "eglot.el (eglot-server-programs, eglot-ensure)",
          "url": "https://github.com/emacs-mirror/emacs/blob/master/lisp/progmodes/eglot.el",
          "publisher": "Emacs mirror on GitHub"
        },
        {
          "title": "lsp-mode: JavaScript/TypeScript (ts-ls)",
          "url": "https://emacs-lsp.github.io/lsp-mode/page/lsp-typescript/",
          "publisher": "lsp-mode documentation"
        },
        {
          "title": "typescript-language-server",
          "url": "https://github.com/typescript-language-server/typescript-language-server",
          "publisher": "typescript-language-server on GitHub"
        }
      ],
      "updated": "2026-10-20"
    },
    {
      "id": "helix",
      "slug": "helix",
      "title": "Helix",
      "editor": "Helix",
      "typescriptSource": "Decided by `typescript-language-server`, which can use the workspace's TypeScript or a `tsserver.path` you configure",
      "languageServer": "`typescript-language-server`, the default for JavaScript, JSX, TypeScript and TSX in Helix's language list",
      "setup": "typescript-language-server",
      "checkedHere": "Not run in Helix for this page. The configuration is from Helix's language documentation and its built-in `languages.toml` linked below; what the server reports comes from TypeScript's language service, which the site's tests run.",
      "summary": "Set up Helix for type-checked JavaScript: the typescript-language-server it uses by default, its jsconfig.json root detection, and checking it agrees with tsc.",
      "intro": [
        "Helix needs no plugin for JavaScript: its built-in `languages.toml` assigns `typescript-language-server` to JavaScript, JSX, TypeScript and TSX, and uses `package.json` and `jsconfig.json` as root markers for JavaScript. Install the server with npm and Helix starts it; TypeScript's own server then checks each file with the nearest `jsconfig.json`, so the errors are tsc's errors.",
        "`hx --health` shows whether Helix can find the language server for each language."
      ],
      "examples": [],
      "sections": [
        {
          "id": "install",
          "heading": "Install the server, and override settings per project",
          "body": [
            "`npm install -g typescript-language-server typescript` puts the server on your `PATH`. Settings go in `languages.toml`, either in your Helix config folder or in a `.helix/languages.toml` inside the project, which Helix merges with the built-in file. The `config` table of a language server becomes its initialization options; the example names the project's TypeScript explicitly with an absolute path."
          ],
          "snippets": [
            {
              "file": ".helix/languages.toml",
              "lang": "toml",
              "code": "# the built-in default for JavaScript, written out\n[[language]]\nname = \"javascript\"\nlanguage-servers = [\"typescript-language-server\"]\n\n# optional: run this project's TypeScript (an absolute path to typescript/lib)\n[language-server.typescript-language-server.config]\ntsserver = { path = \"/home/you/shop/node_modules/typescript/lib\" }"
            }
          ]
        },
        {
          "id": "typescript-version",
          "heading": "Which TypeScript it runs",
          "body": [
            "Per its documentation, `typescript-language-server` reports one of three sources for its TypeScript: the workspace, a `tsserver.path` from its initialization options, or its bundled copy. Keeping `typescript` in the project's dev dependencies, and opening Helix at the project root, lets it use the same version as `npm run lint`; the `tsserver.path` setting above removes any doubt."
          ]
        },
        {
          "id": "differs",
          "heading": "What differs from tsc",
          "body": [
            "Helix shows diagnostics for the files you open, in the gutter and inline. TypeScript's suggestions come through the server as well, though `tsc` never prints them; code actions offer the quick fixes."
          ]
        },
        {
          "id": "match",
          "heading": "Make sure it matches tsc",
          "body": [
            "Run `npm run lint` in a terminal, open a reported file in Helix, and compare the codes. If Helix shows nothing at all, `hx --health` tells you whether the server was found."
          ]
        }
      ],
      "gotchas": [
        "The built-in configuration sets the server's inlay hint options for JavaScript (parameter names, inferred types); inlay hints are display only and have nothing to do with errors.",
        "A server that is not on `PATH` fails quietly in the editor; `hx --health` is the quickest check."
      ],
      "related": [
        "editors/neovim",
        "config/check-js",
        "start/node-esm"
      ],
      "sources": [
        {
          "title": "Language configuration (languages.toml)",
          "url": "https://docs.helix-editor.com/languages.html",
          "publisher": "Helix documentation"
        },
        {
          "title": "Language support",
          "url": "https://docs.helix-editor.com/lang-support.html",
          "publisher": "Helix documentation"
        },
        {
          "title": "languages.toml (built-in defaults)",
          "url": "https://github.com/helix-editor/helix/blob/master/languages.toml",
          "publisher": "Helix on GitHub"
        },
        {
          "title": "typescript-language-server configuration",
          "url": "https://github.com/typescript-language-server/typescript-language-server/blob/master/docs/configuration.md",
          "publisher": "typescript-language-server on GitHub"
        }
      ],
      "updated": "2026-10-20"
    }
  ]
}