tsgolint v7 lanza linting consciente de tipos escrito en Go
tsgolint v7 ejecuta en Go las reglas conscientes de tipos de typescript-eslint. Cubre 59 de las 61 reglas, y las dos cifras de velocidad del propio proyecto no coinciden.
4 min de lectura

En cifras
- typescript-eslint type-aware rules implemented
- 59 of 61
- speedup over ESLint measured in the Oxc project's own blog post
- 12-18x
- speedup the same project's README claims for the same tool
- 20-40x
- typeorm
- 18x
- microsoft/typescript
- 14x
- vuejs/core
- 13x
- microsoft/vscode
- 12x
El linting consciente de tipos (type-aware linting) para TypeScript ya tiene una implementación estable escrita en Go. El proyecto Oxc anunció tsgolint v7.0.2000 el 22 de julio de 2026, y el reportaje de InfoQ del 11 de septiembre de 2026 le dio una atención más amplia. Cubre 59 de las 61 reglas conscientes de tipos de typescript-eslint.
La distinción importa más de lo que parece. La mayoría de las reglas de lint solo necesitan leer la forma de su código: un punto y coma que falta, una variable sin usar. Las reglas conscientes de tipos necesitan saber qué son las cosas en realidad. Preguntar si una promesa llega a esperarse con await es preguntar al verificador de tipos, y el verificador de tipos es la parte lenta.
Por eso estas reglas tienen fama de hacer que una pasada de lint tarde minutos. tsgolint no reimplementa el verificador de tipos para evitar ese coste. Construye programas TypeScript reales sobre typescript-go, que el README de GitHub del proyecto describe como «la implementación de TypeScript de Microsoft», y apunta a TypeScript 7, con nombre en clave Project Corsa.
Las propias cifras del proyecto no coinciden
Aquí el relato se vuelve incómodo, y vale más decirlo con claridad que elegir la cifra más amable.
La entrada del blog de Oxc da tiempos detallados en un Apple M4 Pro de 12 núcleos, comparando con ESLint más typescript-eslint en configuraciones equivalentes. Muestran una mejora de 12 a 18 veces: microsoft/vscode pasa de 83,2 segundos a 6,96 segundos, microsoft/typescript de 27,2 a 1,94, typeorm de 13,2 a 0,75 y vuejs/core de 12,3 a 0,95.
El propio README del proyecto resume sus benchmarks de otra manera. Informa de 22 a 34 veces en los mismos cuatro repositorios y afirma que la herramienta es «20-40x más rápida que ESLint + typescript-eslint en repositorios grandes».
Ambas afirmaciones salen del mismo proyecto, sobre la misma herramienta, frente a la misma comparación. El reportaje de InfoQ cita el rango inferior. No hemos visto una explicación de la diferencia, y ninguna de las dos cifras se ha reproducido de forma independiente. Trate el 12-18x del blog como la cifra con cálculos visibles detrás, y mida su propio repositorio antes de presupuestar con cualquiera de las dos.
El blog sí explica de dónde salen las ganancias: «rutas rápidas que evitan consultas costosas al verificador de tipos cuando la sintaxis ya da la respuesta». Una regla, dice, resultó «35 veces más rápida en VS Code».
Versión 7 de un proyecto que nunca tuvo una versión 1
tsgolint saltó directamente de una línea experimental 0.x a una v7 estable, lo que parece un salto de marketing y no lo es.
La versión ahora sigue al compilador que incorpora. En v7.0.2000, el 7.0.2 es la versión de TypeScript, y el contador final es el número de parche propio de tsgolint, que se reinicia cada vez que cambia la versión de TypeScript. InfoQ cita el razonamiento: «tsgolint ahora se versiona respecto al compilador que incorpora». El efecto práctico es que la cadena de versión le dice qué verificador de tipos está recibiendo.
| Detalle | |
|---|---|
| Versión estable | v7.0.2000, 22 de julio de 2026 |
| TypeScript seguido | v7.0.2 |
| Reglas implementadas | 59 de 61, frente a 43 en la alfa de diciembre |
| TypeScript mínimo | 7.0 |
| Instalación | pnpm add -D oxlint oxlint-tsgolint@7 |
| Ejecución | pnpm oxlint --type-aware |
El código empezó como un prototipo dentro de la organización typescript-eslint, creado por el colaborador auvred, y el fork de Oxc lo continúa con permiso de ese autor.
Qué significa esto para los desarrolladores
La restricción que hay que comprobar primero es TypeScript 7. El linting consciente de tipos exige aquí la 7.0 o posterior, e InfoQ señala que algunas opciones antiguas de tsconfig y algunas funciones de TypeScript 6 siguen sin soporte. Si su build está en TypeScript 6, esto es algo que planificar, no algo que adoptar esta tarde.
Si ya está en la 7, el experimento honesto es una única ejecución cronometrada. Instale los dos paquetes, ejecute pnpm oxlint --type-aware sobre su repositorio y compare con su invocación actual de ESLint. Su propia cifra vale más que cualquier tabla de benchmarks, y este es un caso en el que las cifras publicadas ni siquiera son coherentes entre sí.
Las dos reglas que faltan importan más de lo que sugiere el recuento. Compruebe si alguna de las dos que no llegaron es una de las que depende su equipo. Una suite de lint que corre 12 veces más rápido pero descarta en silencio la regla que atrapa su clase de errores es un mal trato.
Hay aquí un patrón más amplio que conviene señalar. Reescribir herramientas de desarrollo en un lenguaje compilado por velocidad se ha vuelto rutina este año. Debian Code Search abandonó su última dependencia de C en favor de Go puro e igualó a la versión en C. El autor del enlazador mold está reescribiéndolo de C++ a Rust. Lo distinto de tsgolint es que no reescribió la parte difícil. Incorporó el propio compilador de Microsoft y optimizó a su alrededor, que es una forma mucho más barata de ser correcto.
Fuentes
Artículos relacionados

La reescritura de mold en Rust aspira a ser el enlazador de Linux
Mold enlaza 4,9 veces más rápido que LLVM lld. Su autor lo está reescribiendo en Rust y quiere que las distribuciones lo instalen como /usr/bin/ld.

GNU Automake 1.19 corrige un error de 14 años en dist
GNU Automake 1.19, su primera versión en 15 meses, corrige un error de 14 años que rompía comandos simultáneos como make dist-bzip2 dist-xz.

LLVM debate compilar ClangIR por defecto
Una RFC de LLVM propone compilar ClangIR dentro de Clang por defecto. Nadie lo usaría sin un indicador, pero hay estimaciones que doblan los tiempos de compilación.