Discusión: 257 warnings de lint en main y el ruleset de oxlint que se mueve solo

[Zenemig]

⚠️ Discusión, no tarea lista para tomar. Hay cuatro caminos razonables y conviene elegir uno antes de que alguien mande un PR.

Lo que pasa

En main limpio, pnpm lint emite hoy 257 warnings de la regla one-var, repartidos en 14 archivos:

src/components/ch-accordion/ch-accordion.plugin.spec.tsx
src/components/ch-button/ch-button.plugin.spec.tsx
src/components/ch-checkbox/ch-checkbox.plugin.spec.tsx
src/components/ch-divider/ch-divider.plugin.spec.tsx
src/components/ch-input/ch-input.plugin.spec.tsx
src/components/ch-link/ch-link.plugin.spec.tsx
src/components/ch-radio/ch-radio.plugin.spec.tsx
src/components/ch-select/ch-select.plugin.spec.tsx
src/components/ch-switch/ch-switch.plugin.spec.tsx
src/components/ch-tabs/ch-tabs.plugin.spec.tsx
src/components/ch-tabs/ch-tabs.tsx
src/components/ch-textarea/ch-textarea.plugin.spec.tsx
src/tokens/tokens.d.ts
src/tokens/tokens.ts

Todos son la misma cosa: «Combine this with the previous const statement».

Por qué nadie se dio cuenta

Dos razones que se combinan:

1. oxlint está declarado como ^1.77.0, y la versión instalada hoy es 1.78.0. Esa minor agregó one-var a su conjunto de reglas por defecto. O sea, el ruleset cambió sin que nadie modificara package.json ni .oxlintrc.json — el rango con caret lo dejó entrar solo.

2. oxlint termina con exit code 0 porque son warnings, no errores. Así que check-pr sigue en verde y los 257 warnings solo se ven si alguien lee la salida completa del comando.

No es culpa de Dependabot: los PRs #26–#28 no tocaron oxlint. Fue el rango con caret al reinstalar.

Por qué vale decidirlo y no dejarlo

Un lint que grita 257 veces es un lint que nadie lee. El día que aparezca un warning que sí importa, va a estar enterrado entre 257 que no. Y como el exit code es 0, tampoco hay nada que lo frene en CI.

Dos de los archivos afectados (src/tokens/tokens.ts y src/tokens/tokens.d.ts) son además generados por toki, así que ahí no se puede arreglar el código — solo ignorarlos o desactivar la regla.

Los caminos posibles

1. Desactivar one-var en .oxlintrc.json

Es lo que yo sugiero. La regla es una preferencia de estilo sobre si se combinan declaraciones const consecutivas, no detecta ningún bug. 257 apariciones en archivos de test son ruido, no señal. Un PR de una línea y el lint vuelve a servir para algo.

2. Arreglar las 257 apariciones

Deja el lint estricto de verdad. Pero es un diff enorme en archivos de test por una cuestión de estilo, y no se puede completar: dos de los archivos son generados, así que igual habría que ignorarlos o desactivar la regla para ellos. Termina siendo la opción 1 con mucho trabajo extra en el camino.

3. Fijar oxlint a una versión exacta

Ortogonal a las otras y compatible con cualquiera. Hoy, cualquier minor de oxlint puede sumar reglas nuevas y cambiar la salida del lint sin que nadie lo pida. Fijarlo exacto (y dejar que Dependabot proponga las subidas, que es justo para lo que está) hace que los cambios de ruleset lleguen como PR revisable.

Yo la haría además de la 1, no en vez de.

4. Hacer que los warnings fallen (--max-warnings=0)

La más estricta: obliga a resolver cada warning. Solo tiene sentido después de limpiar los 257, y le agrega fricción a cada contribución futura. Para un proyecto de comunidad me parece demasiado, pero lo dejo en la lista.

Mi recomendación

1 + 3: desactivar one-var y fijar oxlint a exacto. Con eso el lint vuelve a ser útil hoy y no se vuelve a mover solo mañana.

Si alguien tiene una razón para querer one-var, la escucho — puede que me esté perdiendo algo de por qué estaba activa.

Detalle aparte, del mismo hallazgo

Mientras revisaba esto vi que en chucao-tokens.json el grupo easing está declarado con "$type": "cubicBezier", pero su único valor es la palabra clave "ease", no el arreglo de cuatro números que pide la especificación DTCG. toki lo tolera sin chistar.

No rompe nada hoy, pero el día que alguien agregue una curva real puede encontrarse con una diferencia de validación. Lo menciono acá para que quede registrado; si les parece que merece su propio issue, lo abro.

[Zenemig]

Evidencia concreta de que el ruleset actual no solo hace ruido, sino que pide cosas imposibles. Salió escribiendo ch-modal (#20), donde aparecieron categorías de regla que no habían salido antes.

capitalized-comments se dispara en líneas de continuación

ch-modal.tsx:79  warning eslint(capitalized-comments): Comments should not begin with a lowercase letter

La línea 79 es la segunda línea de un comentario de dos líneas:

// Absent in server rendering and in the test environment, neither of which
// implements the dialog API.

Para satisfacer la regla habría que escribir «Implements» en mitad de una oración, o no envolver los comentarios nunca. O sea: la regla es incompatible con envolver comentarios en dos líneas, que es lo que hace todo el repo. No hay forma de cumplirla sin escribir peor inglés.

prefer-spread contradice a TypeScript

ch-modal.plugin.spec.tsx:81  warning unicorn(prefer-spread): Prefer the spread operator (...) over Array.from()

Pero escribirlo con spread no compila:

TypeScript: Type must have a '[Symbol.iterator]()' method that returns an iterator

Llegué a Array.from() justamente porque el spread falla el build. El linter pide lo que el compilador rechaza. No es una preferencia de estilo: son dos herramientas del repo pidiendo cosas opuestas, y una de las dos siempre va a estar en rojo.

Y las de siempre

one-var sigue siendo la mayoría del ruido (unas 270 ocurrencias), más no-magic-numbers disparándose con 0:

ch-modal.tsx:103  warning eslint(no-magic-numbers): No magic number: 0

por if (scrollbar > 0).

Lo que esto cambia respecto de mi propuesta original

Sigo recomendando desactivar one-var y fijar oxlint a versión exacta, pero ahora agregaría capitalized-comments, prefer-spread y no-magic-numbers a la lista de desactivar — no porque den lata, sino porque dos de ellas no se pueden cumplir: una pelea con envolver comentarios, la otra con el compilador.

El punto de fondo no cambia: un lint que grita ~280 veces, y donde algunas advertencias son imposibles de resolver, es un lint que nadie lee. Y como el exit code es 0, nada lo frena.

Basta con que alguien diga «sí» y lo mando en un PR de pocas líneas.

[hectorpalmatellez]

Ooooooo que feo el one-var, desactivémoslo nomás, con las otras reglas ruidosas.
Dejemos oxlint en 1.78.0, de ahí con dependabot vamos viendo.