Tslint: no-unused-variable TypeError: no se puede leer la propiedad '1' de nulo

Creado en 17 may. 2018  ·  14Comentarios  ·  Fuente: palantir/tslint

Informe de error

  • __TSLint versión__: 5.10.0
  • __Versión de TypeScript__: 2.8.1
  • __Ejecutando TSLint vía__: CLI

El código de TypeScript está ligado

import { A, B, C } from './file';

console.log('No imports used');

export const D = 4;

con tslint.json configuración:

{
  "rules": {
    "no-unused-variable": [true, {"ignore-pattern": "^_"}]
  }
}

Comportamiento real

The 'no-unused-variable' rule threw an error in '/Users/andrew.mitchell/Documents/Projects/test/test.ts':
TypeError: Cannot read property '1' of null
    at walk (/Users/andrew.mitchell/Documents/test/node_modules/tslint/lib/rules/noUnusedVariableRule.js:105:54)
    at Rule.AbstractRule.applyWithFunction (/Users/andrew.mitchell/Documents/test/node_modules/tslint/lib/language/rule/abstractRule.js:39:9)
    at Rule.applyWithProgram (/Users/andrew.mitchell/Documents/test/node_modules/tslint/lib/rules/noUnusedVariableRule.js:32:21)
    at Linter.applyRule (/Users/andrew.mitchell/Documents/test/node_modules/tslint/lib/linter.js:194:29)
    at /Users/andrew.mitchell/Documents/test/node_modules/tslint/lib/linter.js:139:85
    at Object.flatMap (/Users/andrew.mitchell/Documents/test/node_modules/tslint/lib/utils.js:151:29)
    at Linter.getAllFailures (/Users/andrew.mitchell/Documents/test/node_modules/tslint/lib/linter.js:139:32)
    at Linter.lint (/Users/andrew.mitchell/Documents/test/node_modules/tslint/lib/linter.js:99:33)
    at /Users/andrew.mitchell/Documents/test/node_modules/tslint/lib/runner.js:209:32
    at step (/Users/andrew.mitchell/Documents/test/node_modules/tslint/node_modules/tslib/tslib.js:133:27)

Comportamiento esperado

La regla debe advertir All imports in import declaration are unused. para la línea 1.

Esto es causado por noUnusedVariableRule.ts # L123 porque el mensaje failure es All imports in import declaration are unused. , que no tiene un nombre de variable para que la expresión regular lo encuentre.

Esta regla funciona correctamente si no se especifica la opción ignore-pattern ya que no intentará verificar el nombre de la variable.

Fixed Bug

Comentario más útil

Definir noUnusedLocals y noUnusedParameters en compilerOptions no es exactamente lo mismo que no-unused-variable tslint. A partir de ahora, las variables no utilizadas bloquean la compilación o pasan desapercibidas y ya no hay modo de advertencia 😞

Todos 14 comentarios

Buen hallazgo @hotforfeature. Comencé a abordar esto en https://github.com/palantir/tslint/pull/3919 porque se relacionaba con algunos cambios que se avecinan en TS 2.9 que solo exacerbarán este problema.

Mi PR evita que se lance una excepción, sin embargo, simplemente ignora ignorePattern en los casos que mencionaste, lo cual no es bueno. Creo que tendremos que agregar algún tipo de código complejo como lo que hacemos para las correcciones automáticas de importación en este momento: /

Me pregunto si deberíamos pensar en desaprobar esta regla. tsc ahora proporciona una forma de ignorar sus advertencias y brinda soporte para correcciones automáticas para sus advertencias a través de un IDE.

Por lo que puedo ver, el principal beneficio de esta regla es ignore-pattern , pero es difícil implementarlo correctamente de la forma en que la regla ahora está escrita para depender de los diagnósticos de tsc. TSLint también es un poco más flexible que tsc con respecto a la desactivación de reglas en ciertos archivos. @suchanlee ¿ alguna idea sobre todo esto? Sé que has arreglado esta regla recientemente.

Mi caso de uso principal para esta regla es arreglar automáticamente los problemas en la confirmación en un gancho de git al realizar el linting. Así que sigo pensando que hay un gran valor aquí, incluso si tsc ofrece algo a través de integraciones IDE.

@JKillian Creo que la regla está comenzando a ser cada vez más costosa de admitir con el soporte de TSLint para múltiples versiones de Typecript y los cambios continuos en el comportamiento de Typecript. Y dado que TypeScript es compatible con la función, deberíamos inclinarnos hacia su uso. Pero como las versiones anteriores de TS no lo admiten, no creo que debamos eliminarlo. Sin embargo, creo que deberíamos empezar a pensar en desaprobar la regla y trabajar con la gente de TS para soportar mejor los flujos de trabajo actuales de TSLint con TS.

Apoyaría la propuesta de

@hotforfeature : reconozca su caso de uso y considérelo razonable. Sin embargo, debido a la complejidad de la regla, creo que la vamos a desaprobar (ver # 3919).

Sin embargo, como siempre, cualquiera puede copiar el código fuente de la regla y moverlo a un paquete externo y seguir usándolo / mejorándolo de esa manera.

Por lo que vale:

{
  "compilerOptions":  {
    "noUnusedLocals": true,
    "noUnusedParameters": true,
  }
}

Usar lo anterior en tsconfig permite deshabilitar la regla no-unused-variable lint.

no-unused-variable ahora está en desuso, y el compilerOptions anterior es la solución oficial ahora.

Definir noUnusedLocals y noUnusedParameters en compilerOptions no es exactamente lo mismo que no-unused-variable tslint. A partir de ahora, las variables no utilizadas bloquean la compilación o pasan desapercibidas y ya no hay modo de advertencia 😞

@giladgray , @killtheliterate escribió:

El uso de lo anterior en tsconfig permite deshabilitar la regla de pelusa sin variables no utilizadas.

No quiero deshabilitar esta regla, porque como escribió @kachkaev

Definir noUnusedLocals y noUnusedParameters en compilerOptions no es exactamente lo mismo que no-unused-variable tslint

Mi caso de uso es el código generado. Quiero que mi código escrito manualmente siga esta regla, pero para evitar que el generador de código sea enormemente complejo, me gustaría deshabilitar esta regla en el código generado (o al menos en algunas secciones del código generado), eso es algo que puede ' t hacerlo con las opciones del compilador de TypeScript 😞

Como mínimo, esta desaprobación debe documentarse en el sitio web de TSLint , pero estoy totalmente de acuerdo en que esta desaprobación fue prematura. ¿Algún plan para reconsiderar? ¿Se aceptará una contribución comunitaria?

Esta desaprobación es ridícula. Los indicadores del compilador son un reemplazo TERRIBLE. Rompen la construcción y no se arreglan solos. ¿Cómo es esa una solución razonable para señalar a la gente? Si la opción ignore-pattern es demasiado difícil de hacer que funcione ahora, desapruebe eso.

👋 amigos, simplemente vinculando esto a https://github.com/palantir/tslint/issues/4232. Está bien entendido y acordado que las opciones del compilador incorporado _no_ son un reemplazo suficiente para no-unused-variable . La implementación original de la regla no funcionó bien con otras herramientas de TS y tuvo que desactivarse. # 4232 rastrea la búsqueda de una manera de habilitarlo nuevamente.

Mientras tanto, puede usar algo como tsc --noEmit --noUnusedLocals --noUnusedParameters como una herramienta separada para usar las comprobaciones integradas. Sí, eso no es tan bueno como un no-unused-variables configurable.

Continuar la discusión en # 4100 y # 4232

¿Fue útil esta página
0 / 5 - 0 calificaciones