Pretty TypeScript Errors: a VSCode extension that rewrites tsc output into readable types

The problem: TypeScript diagnostics are written for the compiler, not the reader

TypeScript error messages degrade as type complexity rises. The README puts it bluntly: at some point TypeScript throws "a shitty heap of parentheses and `...`". The extension's before-and-after images show the same diagnostic rendered two ways, with the raw form on the left and a highlighted, structured form on the right.

The intended audience is anyone who spends the day inside VSCode reading type errors: application developers working with React, Vue, Svelte or Astro files, and library authors whose generic signatures produce long inferred types. The README lists Node and Deno error reporters in .ts files, JSDoc type errors in .js and .jsx, React, Solid and Qwik errors in .tsx and .mdx, Astro, Svelte and Vue files when TypeScript is enabled, and Ember and Glimmer errors plus template issues reported by Glint in .hbs, .gjs and .gts.

That list is the scope boundary. This is not a general editor tool and not a linter. It changes how diagnostics are displayed inside one editor.

How the extension rewrites a diagnostic before you see it

The README's "Why isn't it trivial" section is the most useful part of the repository for judging the design, because it names three concrete obstacles.

First, TypeScript error text contains types that are not valid TypeScript. The output includes fragments such as `... more ...` and `{ ... }`, used inconsistently, and some types are cut off in the middle because they are too long. Any renderer therefore has to parse a non-grammar, not a language.

Second, the types cannot be highlighted with the normal TypeScript grammar, because the `type X = ...` prefix that a grammar expects is missing. The author wrote a new TextMate grammar, described as a superset of the TypeScript grammar called `type`, to highlight these fragments.

Third, VSCode markdown blocks styling. There is no inline code block in VSCode markdown, so the extension puts a code block inside a codicon icon, which the README says is the only element that can be inlined. The consequence is stated directly: that is why the rendered type cannot be copied. The README points readers to the original error pane for copying, and ships docs/hide-original-errors.md for people who want the original errors hidden, calling that hack necessary because of VSCode limitations.

On top of the rendering, the extension adds three buttons: one that jumps to the relevant type declaration, one that opens the error at typescript.tv, and one that opens ts-error-translator for a plain-English explanation.

Install Pretty TypeScript Errors and see a real error rendered

The README gives one install command. Run it from a terminal where the `code` shell command is on your PATH:

code --install-extension yoavbls.pretty-ts-errors

After it completes, the extension is installed in that VSCode instance. The README also describes the alternative: search for `pretty-ts-errors` in the VSCode marketplace. There is no configuration step in the README, so the first real use is simply opening a TypeScript file that has a type error and hovering over the squiggle.

The repository ships example files you can open to see the rendering without writing your own failing code: examples/errors.ts, examples/errors.js and examples/errors.vue. The expected result is the diagnostic shown with theme-colored types instead of a flat wall of parentheses, plus the navigation buttons described above.

If the copy behaviour matters to you, the README points to a separate document:

# follow the instructions in ./docs/hide-original-errors.md

That file is where the project explains hiding the original errors so the pretty version becomes the copyable one. Treat that document as required reading before you decide the extension fits your workflow.

The copyability trade-off and where the extension does nothing for you

The honest limitation is stated by the project itself: styled types in the hover cannot be copied, because the styling relies on a code block inside a codicon. The workaround is a documented hack in docs/hide-original-errors.md, and the README attributes the need for it to VSCode limitations rather than to a fixable bug. If your habit is to select an error message and paste it into a search engine or a chat, the default experience will frustrate you until you apply that hack.

Second, the extension is VSCode-specific. The README's support list is entirely about file types and language servers inside VSCode. JetBrains is represented only by a badge linking to a GitHub discussion thread, not a shipped plugin. If your team standardizes on WebStorm or another JetBrains IDE, the README does not document a working path for you.

Third, this is a rendering layer. It does not suppress, filter or fix diagnostics, and nothing in the README suggests it changes which errors the TypeScript server reports. If your problem is that a diagnostic is wrong or noisy, this extension will only show you the same wrong or noisy diagnostic in a nicer font.

Alternatives: ts-error-translator and plain tsc output

The README itself links to ts-error-translator, which the extension exposes as one of its three buttons. The difference in approach is worth spelling out. ts-error-translator is a separate tool that maps a TypeScript error code to a plain-English explanation. It answers the question "what does this error mean". Pretty TypeScript Errors answers "what does this type actually look like", by highlighting the structure and letting you click through to the declaration. They are complementary, and the extension treats the translator as a destination rather than a competitor.

The other alternative is doing nothing: reading raw output from `tsc` or the VSCode problem pane. That output is exact, complete and copyable, and it is what the extension is trying to improve on. For CI logs, terminal output and code review comments, raw text remains the format everyone shares. The extension only helps at the moment you are looking at a hover in VSCode.

A third point of comparison is the editor's own rendering. VSCode already shows the full diagnostic text in the Problems panel; the extension changes the hover presentation, not the underlying data.

Maintenance, licence and what a fork costs

The repository is not archived, and the last push was on 2026-09-10. The most recent release listed is v0.8.5 on 2026-03-21, following v0.7.0 on 2025-12-25 and v0.6.1 on 2024-11-24. The gap between v0.6.1 and v0.7.0 is roughly thirteen months, so release cadence has been uneven even though the repository is still receiving commits.

The project is MIT licensed. That is permissive: you can fork, modify and redistribute it, including in commercial settings, provided you keep the licence text. This is not legal advice; read the LICENSE file in the repository if the distinction matters to your organisation.

The upgrade cost is low by construction. There is no server, no daemon and no config file documented in the README, so upgrading means letting the marketplace update the extension. The maintenance burden lands on the maintainer instead: the extension depends on parsing TypeScript's error text, and the README's own description of inconsistent `... more ...` and `{ ... }` fragments suggests that a future TypeScript release could change the text and break the rendering. The monorepo uses npm workspaces with turbo, and package.json requires Node >=20 for development, but that only matters if you intend to build from source rather than install the published extension.

Editorial conclusion

Adopt Pretty TypeScript Errors if your team reads TypeScript diagnostics inside VSCode all day and the raw parenthesized type text is the bottleneck. Skip it if you work primarily in Neovim, Zed or a JetBrains IDE, since the README only points to a discussion thread for JetBrains support and does not document editor-agnostic output. Before rolling it out, verify two things yourself: that your theme renders the highlighted types legibly, and whether you need the docs/hide-original-errors.md procedure to make error text copyable.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yoavbls/pretty-ts-errors on GitHub