yats.vim trades speed for a very detailed TypeScript view

What yats.vim changes about the TypeScript you see in Vim

The project bills itself as Yet Another TypeScript Syntax for Vim, adapted from YAJS, and the difference list starts with what the author calls exuberant highlighting, described as the most elaborate or byzantine syntax highlighting for TypeScript. That word choice is the honest summary of the design.

Most of the rest of the list is functional rather than cosmetic. The Web API and DOM keywords are inherited from YAJS, so the file knows about browser globals and not just language keywords. Syntax fold is described as folding long code blocks semantically, which is a stronger claim than the line-based folding Vim offers by default. Old unused syntax definitions were removed.

One naming decision has practical value for other plugins. The group name is prefixed with typescript, not typeScript or TypeScript, and the documentation says this works well with SyntaxComplete, because a plugin that looks up groups by name will find them. Small detail, but the kind of thing that decides whether two plugins can live in the same setup.

The regexp engine warning is not optional advice

The configuration section carries one option and one warning, and the warning is the more important of the two.

The option is a host keyword switch. Setting `let g:yats_host_keyword = 1` configures yats to highlight host specific keywords such as addEventListener, and the default is 1, with 0 turning the highlighting off. A file that mixes browser and server code, or a project that wants a quieter screen, can turn that group off without touching anything else.

The warning concerns the engine. The documentation says to set `set re=0` explicitly in your vimrc, because the old regexp engine will incur performance issues for yats, and because that engine is usually turned on again by other plugins. This is a genuine constraint rather than a preference. A syntax file built from heavy regular expressions will visibly slow down on a large TypeScript file when Vim falls back to its legacy matching path, so an installation that skips this line is not the installation the author had in mind.

The interaction with other plugins is the catch. Because the legacy engine is switched on by other plugins, you may have to re-apply set re=0 after they load.

Concealed glyphs need a font that has them

The syntax can replace tokens with single characters, and the configuration is a set of variables naming one glyph per token:

let g:typescript_conceal_function             = "ƒ"
let g:typescript_conceal_null                 = "ø"
let g:typescript_conceal_undefined            = "¿"
let g:typescript_conceal_this                 = "@"
let g:typescript_conceal_return               = "⇚"
let g:typescript_conceal_prototype            = "¶"
let g:typescript_conceal_super                = "Ω"

The documentation is explicit that this works if your font provides the glyph you want, which is the real dependency here. A terminal with a default monospace font will show replacement characters instead of the intended symbols, and the effect is worse than no concealing at all.

Two settings turn the feature on. The plain route is:

set conceallevel=1

The other route is a toggle bound to the leader key, described as usually the backslash:

map <leader>l :exec &conceallevel ? "set conceallevel=0" : "set conceallevel=1"<CR>

A toggle is the more useful of the two, since the same buffer reads differently depending on whether you are writing or reading code.

Snippets, tagbar and the repository layout

Three bundled features sit alongside the highlighting, and each one maps to a directory in the tree. The syntax file is under syntax/, with ftdetect/ and ftplugin/ alongside it, plus indent/ for indentation behaviour, ctags/ for tag generation, compiler/ for compiler messages and autoload/ for autoloaded functions. The UltiSnips/ directory holds the bundled snippets, and tagbar support is built in rather than bolted on.

That last point is a structural choice. Tagbar is a Vim plugin that shows a tag outline derived from the syntax file's tag definitions, and it can only show something if the syntax file declares the tags. A syntax file written to support tagbar has to be written differently from one that only colours tokens, which is part of why this file is described as elaborate.

The tree also has data/, test/, a Makefile with a config.mk, a merge.js with a merged/ directory, a package.json and a.gitmodules file. The presence of merge.js and a merged directory points to an assembly step that combines parts of the syntax into the shipped file, and the package.json lists devDependencies on camel-case, is-upper-case and js-yaml, which are the kind of libraries such a step would use. The.gitmodules file means the UltiSnips directory is a submodule, so the snippets are not in the repository proper until it is initialised.

Installing without a documented command

There is no install instruction in the documentation, which is the first thing to note when you are trying to set this up.

What the repository offers instead is a Makefile whose own header describes it as a tool to install, uninstall and link vim plugin files, together with a config.mk, and the project has a CI workflow for the build. So the pieces for a make based install exist, but the README does not state the targets, so the exact invocation has to be read out of the Makefile rather than copied from a guide.

For a Vim plugin manager user the situation is simpler and vaguer at the same time. Vim plugin managers normally clone a repository into a runtime path directory, and this repository's layout, with syntax/, plugin files, ftplugin/ and ftdetect/, is the layout such a manager expects. What it will not do for you is initialise the .gitmodules entry, so the UltiSnips snippets can be missing after an otherwise successful install, and that failure looks like a missing feature rather than a missing submodule.

There is also no release to install from. The repository has no GitHub releases, so there is no tag to pin and no archive to download. The version field in package.json reads 1.0.0, which describes the JavaScript side of the repository rather than a published Vim plugin release, so it is not a version you can use to pin a plugin manager.

The alternative is YAJS, or whatever your editor already ships

The project this one was adapted from is YAJS, and that is the most direct comparison available, since both are Vim syntax files for the same family of languages. The difference in approach is that YAJS is the up-to-date JavaScript syntax, and yats.vim takes it as the base and adds TypeScript specific work: exuberant highlighting, semantic folding, UltiSnips snippets, built-in tagbar support, and a typescript group prefix chosen to cooperate with SyntaxComplete.

The other alternative is the syntax file that came with your editor, which needs no install and no submodule and no font. The trade is the same one this project is making: an elaborate file that shows more of the language, against a plain one that loads instantly and never surprises you.

For anyone already on YAJS the migration question is narrow and answerable: install yats.vim, set re=0, check the group naming does not collide with another plugin's expectations, and keep the Vim font in mind. For someone starting from the default syntax, the deciding factor is whether you write enough TypeScript to notice the difference between the two.

Licence, no releases, and a repository that is still being touched

The licence is the same as Vim, stated in the documentation and recorded in package.json as the license field, and the LICENSE file sits at the repository root. Vim's licence is a charityware licence, so redistribution of the plugin carries the conditions that Vim itself carries. This is a licensing observation rather than advice about how to use it.

On maintenance, the repository is not archived and the last push was on 2026-10-06. Activity exists in the tree: a CHANGES.markdown file, a CI workflow referenced by the build badge, and a test directory.

The gap is in how that activity reaches users. There are no GitHub releases, so there is no versioned artefact, no changelog tied to a tag, and no upgrade path other than tracking the default branch. The credits section names the people whose work the syntax is based on, among them othree, whose YAJS is described as the most up-to-date js syntax for Vim, and it credits the original authors of the file this one descends from.

That arrangement is normal for a long lived Vim plugin and it is also the maintenance cost to price in. You are taking the current state of a branch, and the syntax definitions change without a version marker to tell you what moved.

Editorial conclusion

yats.vim fits a Vim user who works in TypeScript all day and wants the file to look like the language is understood, especially with a patched font that ships the concealment glyphs. It does not fit a setup that keeps Vim's legacy regexp engine enabled, since the documentation is explicit that the old engine will hurt, and it does not fit a team that needs a reproducible install, because there is no release and no documented install command. Before adopting it, add set re=0 to your vimrc, check the font for the glyphs behind the conceal variables, and initialise the UltiSnips submodule before expecting the bundled snippets to be there.

Frequently asked questions

Official sources

1. HerringtonDarkholme/yats.vim on GitHub
2. Issues
3. License: Vim
4. README