# typescript-language-server wraps a VSCode internal extension and names its own successor > The server is a thin LSP layer over the Typescript Language Features extension that VSCode bundles internally, and the write-up says plainly that it is not used in VSCode and that Microsoft's TypeScript 7, written in Go with its own LSP implementation, may supersede it. The six code action kinds it announces include one called fixAll that fixes three specific things. **typescript-language-server/typescript-language-server** — Unofficial TypeScript & JavaScript Language Server - Repository: https://github.com/typescript-language-server/typescript-language-server - Website: https://www.npmjs.com/package/typescript-language-server - Stars: 2,572 · Forks: 187 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/typescript-language-server-typescript-language-server ## The install command pins a TypeScript major next to the server There is one installation line, and it installs two things at once: ```sh npm install -g typescript-language-server typescript@6 ``` The TypeScript major is part of the command rather than an implied peer dependency, which means the compiler your editor analyses with is the one you chose at install time and not whatever happens to sit in the nearest node_modules. The whole command line interface is four options: ``` Usage: typescript-language-server [options] Options: -V, --version output the version number --stdio use stdio (required option) --log-level A number indicating the log level (4 = log, 3 = info, 2 = warn, 1 = error). Defaults to `3`. -h, --help output usage information ``` So the transport is stdio and it is marked required, there is no TCP or socket mode, no configuration file flag, and no way to point the server at a different TypeScript installation. Log verbosity is numeric rather than named, counting down from 4 for log to 1 for error, and the default is 3, which is info. Configuration is not handled on the command line at all; the write-up sends you to docs/configuration.md instead. ## What it wraps is an internal VSCode extension, and the write-up says so The architecture is one hop from the editor, and the write-up is unusually direct about what that hop is. The TypeScript project ships a `tsserver` component exposing a custom API for gathering intelligence about a TypeScript or JavaScript project. The VSCode team built a project called Typescript Language Features on top of it and bundled that as an internal extension inside VSCode. Because that extension does not speak the standardized Language Server Protocol, other editors that implement LSP cannot use it directly. This project exists to put a thin LSP interface on top of that extension's code base. Two disclaimers follow immediately. The project is not directly associated with Microsoft and is not used in the VSCode editor, and anyone with an issue about VSCode functionality is told to report it in Microsoft's repository instead. That is the structural risk stated plainly: the thing doing the real work is a private component of somebody else's editor, and the compatibility surface is whatever that bundle happens to expose. ## The write-up names the successor it expects to be replaced by There is a paragraph about the future, and it is not reassuring. Microsoft is working on TypeScript 7, written natively in Go, which will include the LSP implementation and will hopefully supersede this project. That single sentence reframes everything else in the document: the whole design exists to translate tsserver's custom protocol into LSP, and if the compiler ships its own LSP server, the translation layer has nothing left to translate. The version numbers tell the same story from the other side. The install command asks for typescript@6, the three newest tags are v5.3.0 from 2026-05-21, v6.0.0 from 2026-08-20 and v6.0.1 from 2026-09-24, and the manifest version is 6.0.1, which matches the newest tag rather than running ahead of it. The last push on the default branch is dated 2026-10-02, about a week after that tag. Project history is also recorded: the code was originally based on concepts from prabirshrestha's project of the same purpose, was maintained by TypeFox, and is now maintained by a community of contributors. ## The code action called fixAll does not fix all Six code action kinds are announced, and the naming is where the trap sits. `source.fixAll.ts` is described as fixing a couple of specific issues despite the name, namely unreachable code, await in non-async functions, and incorrectly implemented interface members. The rest are narrower still: `source.removeUnused.ts` removes declared but unused variables, `source.addMissingImports.ts` adds imports for used but not imported symbols, `source.removeUnusedImports.ts` removes unused imports, `source.sortImports.ts` sorts imports, and `source.organizeImports.ts` organizes imports and removes unused ones. Sorting and organizing imports are two separate kinds, so an editor that only enables one of them leaves half the behaviour off. The settings accept either spelling, so both the full kind with its .ts suffix and the short form work, which is convenient and also means a typo in the long form fails silently rather than loudly: ## Four workspace commands are marked non-standard and two have version floors The commands are sent through workspace/executeCommand, and their names encode their status. Four of them are prefixed with a low line character before the type name: `_typescript.goToSourceDefinition`, `_typescript.applyRefactoring`, `_typescript.organizeImports` and `_typescript.applyRenameFile`. A fifth, `typescript.tsserverRequest`, carries no such marker, and it is the escape hatch that forwards an arbitrary command to tsserver with its own arguments and an ExecuteInfo configuration object. Go to Source Definition is documented as supported from TypeScript 4.7. The arguments mix two type namespaces on purpose, with `lsp` referring to the language server protocol types and `tsp` to the typescript server protocol types, so a request like Organize Imports takes an LSP document URI and a tsserver options object in the same call. That options object is where the versioning shows: `skipDestructiveCodeActions` is marked deprecated in favour of `mode`, and is documented as supported from TypeScript 4.4, while `mode` takes three values where All performs destructive actions such as removing unused imports, SortAndCombine does not, and RemoveUnused only removes unused imports. ## Node 22, pnpm, rollup and a bundle size budget The toolchain is pinned hard and the build is a bundle rather than a compile step. The manifest declares node >=22.22.2 as the engine, names pnpm@12.7.0 as the package manager, and ships pnpm-lock.yaml with a pnpm-workspace.yaml beside it. The package is ESM, its published files list is just `lib`, and its single binary entry points at lib/cli.mjs. Both the build and the dev scripts start by removing lib and then run rollup against rollup.config.ts with sourceMap disabled, with a rollup-exit-plugin.js sitting in the repository to make that exit behave. Alongside rollup there is babel.config.cjs and a tsconfig.json for typechecking, a separate tsc-driven typecheck script, and eslint.config.js for linting, so flat configuration is what the repository actually uses. What it does not have is an .eslintrc file: the manifest still carries an eslintIgnore entry written for one, and the lint script still passes the --ext flag that belongs to the older configuration world. Dependency moves run through renovate.json, commits run through husky, and there is a .size-limit.cjs with a size script, so the bundle has a budget that fails a build that outgrows it. ## Tests differ between the watch run and the commit run Two scripts, one test suite, and a deliberate difference between them. The test script sets CONSOLE_LOG_LEVEL=warning through cross-env and runs vitest with coverage, which is the interactive form, while test:commit sets the same variable and runs vitest run, which is the one-shot form used for commits and skips the coverage collection. The vitest configuration lives in vitest.config.ts with a v8 coverage plugin, and the fixtures live in a test-data/ directory at the root, which matters for a project whose whole job is talking to another product's protocol and whose tests therefore need sample projects to talk about. The editor's own configuration is checked in as .vscode/, and the Node version is pinned twice over, in the engines field and in a .nvmrc. Release tooling is automated rather than manual: release-please-config.json with a .release-please-manifest.json drives version bumps, and CHANGELOG.md is the artefact that pipeline writes. A postversion script pushes the tags after the bump, so the release path is a git operation, not a publishing dance. ## The licence is declared in the manifest and empty in the repository field The licence status is one of the things to settle before reuse. The repository's own licence field carries no value, while the package manifest declares Apache-2.0 and a LICENSE file sits at the root of the tree. That is the mismatch to be aware of, and the manifest plus the file are the two places with something concrete behind them. Everything else about the package metadata is unambiguous: the description is a Language Server Protocol implementation for TypeScript using tsserver, the author line credits TypeFox and others, and the repository URL points at this repository rather than at Microsoft. Configuration, meanwhile, is the one topic the write-up refuses to cover in the body, deferring the entire surface to docs/configuration.md. That file is where an editor integrator has to go for settings such as how code actions on save are enabled, and it is the file an editor integrator depends on most directly when wiring this server up. ## Conclusion Reach for this server when your editor speaks LSP but has no TypeScript support of its own, which is the situation it was written for, and expect a small surface: four CLI options, stdio transport, and features that mostly forward to tsserver. Two things to settle before you wire an editor to it. First, the upstream it depends on is an internal VSCode extension that Microsoft ships and does not expose as a stable API, so the layer is only as stable as that bundle, and the write-up itself points you at Microsoft's repository for anything that looks like a VSCode problem. Second, the roadmap already names a successor: TypeScript 7 in Go with its own LSP implementation, which the project says will hopefully supersede this. Read the command names before scripting them, because four of the workspace commands are marked as non-standard in their names, and check the minimum TypeScript version your command needs, since Go to Source Definition starts at TypeScript 4.7. ## FAQ ### How to install TypeScript language server? One global install line covers both the server and the compiler: `npm install -g typescript-language-server typescript@6`. Then start it with stdio transport, which the write-up marks as the required option. ### what is typescript language server An unofficial thin Language Server Protocol interface on top of the Typescript Language Features extension that VSCode bundles internally, so editors that speak LSP can reach the tsserver API. The write-up states it is not associated with Microsoft and is not used in VSCode. ### typescript language server vs tsserver tsserver is the component inside the TypeScript project that exposes a custom API for gathering intelligence about a project. This project is the LSP translation layer in front of it, and the extension it wraps does not speak LSP itself, which is the gap it fills. ### tsgo vs typescript language server Microsoft is working on TypeScript 7 written natively in Go, which will include the LSP implementation and will hopefully supersede this project, according to the write-up. That is the project's own statement about its own roadmap, not a third-party prediction. ## Sources - [Issues](https://github.com/typescript-language-server/typescript-language-server/issues) - [Project website](https://www.npmjs.com/package/typescript-language-server) - [README](https://github.com/typescript-language-server/typescript-language-server/blob/master/README.md) - [Releases](https://github.com/typescript-language-server/typescript-language-server/releases) - [typescript-language-server/typescript-language-server on GitHub](https://github.com/typescript-language-server/typescript-language-server) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/typescript-language-server-typescript-language-server