Tslint: Advertencia: La regla 'no-variable-sin usar' requiere un mensaje de verificación de tipo ...

Creado en 16 jun. 2017  ·  46Comentarios  ·  Fuente: palantir/tslint

Informe de error

con la configuración tslint.json :

{
  "rulesDirectory": [
    "node_modules/codelyzer"
  ],
  "rules": {
    "arrow-return-shorthand": true,
    "callable-types": true,
    "class-name": true,
    "comment-format": [
      true,
      "check-space"
    ],
    "curly": true,
    "eofline": true,
    "forin": true,
    "import-blacklist": [
      true,
      "rxjs"
    ],
    "import-spacing": true,
    "indent": [
      true,
      "spaces"
    ],
    "interface-over-type-literal": true,
    "label-position": true,
    "max-line-length": [
      true,
      140
    ],
    "member-access": false,
    "member-ordering": [
      true,
      {
        "order": [
          "public-static-field",
          "protected-static-field",
          "public-static-method",
          "protected-static-method"
        ]
      }
    ],
    "no-arg": true,
    "no-bitwise": true,
    "no-console": [
      true,
      "debug",
      "info",
      "time",
      "timeEnd",
      "trace"
    ],
    "no-construct": true,
    "no-debugger": true,
    "no-duplicate-super": true,
    "no-empty": false,
    "no-empty-interface": true,
    "no-eval": true,
    "no-inferrable-types": [
      true,
      "ignore-params"
    ],
    "no-unused-variable": true,
    "no-misused-new": true,
    "no-non-null-assertion": true,
    "no-shadowed-variable": true,
    "no-string-literal": false,
    "no-string-throw": true,
    "no-switch-case-fall-through": true,
    "no-trailing-whitespace": true,
    "no-unnecessary-initializer": true,
    "no-unused-expression": true,
    "no-var-keyword": true,
    "object-literal-sort-keys": false,
    "one-line": [
      true,
      "check-open-brace",
      "check-catch",
      "check-else",
      "check-whitespace"
    ],
    "prefer-const": true,
    "quotemark": [
      true,
      "single"
    ],
    "radix": true,
    "semicolon": [
      "always"
    ],
    "triple-equals": [
      true,
      "allow-null-check"
    ],
    "typedef-whitespace": [
      true,
      {
        "call-signature": "nospace",
        "index-signature": "nospace",
        "parameter": "nospace",
        "property-declaration": "nospace",
        "variable-declaration": "nospace"
      }
    ],
    "typeof-compare": true,
    "unified-signatures": true,
    "variable-name": false,
    "whitespace": [
      true,
      "check-branch",
      "check-decl",
      "check-operator",
      "check-separator",
      "check-type"
    ],
    "directive-selector": [
      true,
      "attribute",
      "app",
      "camelCase"
    ],
    "component-selector": [
      true,
      "element",
      "app",
      "kebab-case"
    ],
    "use-input-property-decorator": true,
    "use-output-property-decorator": true,
    "use-host-property-decorator": true,
    "no-input-rename": true,
    "no-output-rename": true,
    "use-life-cycle-interface": true,
    "use-pipe-transform-interface": true,
    "component-class-suffix": true,
    "directive-class-suffix": true,
    "no-access-missing-member": true,
    "templates-use-public": true,
    "invoke-injectable": true
  }
}

¿Qué estoy haciendo mal exactamente?

  • __TSLint versión__: 5.4.3
  • __TypeScript versión__: 2.3.4
  • __Ejecutando TSLint vía__: hilo y línea de comando

Comportamiento real

Al ejecutar tslint con los siguientes parámetros:

tslint --type-check --project tsconfig.json  src/**/*.ts

Recibo la siguiente advertencia:

Could not find implementations for the following rules specified in the configuration:
    Warning: The 'no-unused-variable' rule requires type checking
Try upgrading TSLint and/or ensuring that you have all necessary custom rules installed.
If TSLint was recently upgraded, you may have old rules configured which need to be cleaned up.

Comportamiento esperado

De acuerdo con la documentación de tslint para hacer la verificación de tipos, todo lo que necesito hacer es pasar --type-check --project tsconfig.json pero no parece funcionar.

Question

Comentario más útil

Si observa el archivo Léame de VSCode 1.19, hay una nueva función para registrar esta y otras reglas como advertencias.
Para nosotros, significa:

  • eliminar "no-unused-variable" de tslint.json
  • agregue "noUnusedLocals" a nuestro tsconfig.json

Otras reglas se dejan como ejercicio para el lector ;-)

Tenga en cuenta que tslint es esta extensión, mientras que tsconfig es el comportamiento integrado de VSCode.

Todos 46 comentarios

Complete la plantilla de problemas. ¿Cómo se ve su tslint.json?

Estoy en casa y probé el mismo proyecto y funciona bien. Dejaré esto abierto hasta que llegue a trabajar el lunes para probar nuevamente. Es posible que necesite simplemente reinstalar mis módulos de nodo.

También he actualizado para usar la plantilla de problemas.

En algún momento después de la actualización de tslint (tal vez v4 -> v5), no-unused-variable no están disponibles sin los argumentos --type-check , --project .

Esta opción es difícil de usar y lleva mucho tiempo hasta que se imprimen los resultados después de la actualización, pero es la opción de pelusa más importante y utilizada. ¿Hay alguna forma de usar estas opciones sin argumentos superiores?

En algún momento después de la actualización de tslint (tal vez v4 -> v5), no-unused-variable no está disponible sin los argumentos --type-check, --project.

Estoy pasando --project con tslint --type-check --project tsconfig.json src/**/*.ts

En la computadora de mi casa no tengo este problema, pero sí en la computadora de mi trabajo.

@everedifice hubo errores con la implementación de la regla, casi la desaprobamos (https://github.com/palantir/tslint/issues/1481), y finalmente decidimos mantenerla delegando a la implementación del compilador de no-unused-variable (esto solucionó la mayoría de los errores). Hay muchos hilos de discusión al respecto en este repositorio que le animo a que consulte, en su mayoría vinculados desde el PR que hizo el cambio rotundo (

@mastrauckas Realmente no puedo ayudarlo sin más detalles sobre las diferencias entre sus dos entornos diferentes.

@adidahiya Recibí esto en una tercera computadora que es macOS anoche también. Voy a intentarlo nuevamente en la computadora de mi hogar para ver si todavía sucede.

En general:
computadora 1: Windows 10 completamente actualizado y en este momento no obtengo el error .
computadora 2: macOS completamente actualizado y obtengo el error .
computadora 3: Windows 7 completamente actualizado y obtengo el error .

@everedifice Acabo de publicar una nueva versión de tslint-consistent-codestyle con una nueva regla no-unused que es principalmente como no-unused-variable con algunas características adicionales pero sin la necesidad de usar --project --type-check .

Si está interesado, puede encontrar los documentos aquí: https://github.com/ajafff/tslint-consistent-codestyle/blob/master/docs/no-unused.md

La computadora que pensé que no tenía el problema parece tener el problema después de todo. ¿Es esto un error?

¿Algo nuevo sobre este tema?

Tengo el mismo problema.

El mismo problema, pero con 'Advertencia: La regla' no-variable-no utilizada 'requiere información de tipo'.
y 'Advertencia: la regla' no usar antes de declarar 'requiere información de tipo.' (Puedo ver que el error tipográfico en 'información' se corrigió entre la versión 5.5.0 y 5.7.0, pero eso es lo único que cambió). Lo estoy ejecutando con la versión 2.4.1 de mecanografiado. ¿Alguna noticia sobre ese problema?

El mismo problema aquí

¿Se ha resuelto este problema o alguna solución temporal para dejar de mostrar advertencias?

No creo que esté arreglado. Ni siquiera creo que lo aceptaron como un problema.

Corrección permanente, use no-unused-variable en tsconfig.json en lugar de tslint.json. Si el compilador puede proporcionar la misma funcionalidad, no tiene sentido hacerlo con un linter.

@AnimaMundi, bueno, proporciona la misma funcionalidad, sin embargo, cuando se ejecuta tslint como parte de nuestro proceso de CI, estos deben marcarse durante la prueba, no durante la compilación. No estoy de acuerdo en que esto deba ignorarse / eliminarse porque el compilador lo hace en el momento de la compilación.

@haswalt No veo ninguna razón por la que deba marcarse durante la fase de linting en lugar de la fase de compilación. De todos modos, no importa si estás de acuerdo conmigo o no, no tengo nada que ver con el desarrollo de este proyecto. Acabo de ver que alguien estaba buscando una solución y se la proporcionó.

Similar a la solución de noUnusedLocals y noUnusedParameters en mi tsconfig.json. Los errores aparecen en mi panel de "problemas".

@AnimaMundi @haswalt @keego los méritos de una regla de lint frente a una verificación de compilador para vars no utilizados se han discutido ampliamente en otros hilos de TSLint (https://github.com/palantir/tslint/issues/1481 y hilos vinculados); este tema no es realmente el lugar para ello.

@adidahiya, mi comentario estaba destinado simplemente a compartir una solución para este problema, no a proporcionar comentarios sobre los méritos de las reglas de linter frente a las comprobaciones del compilador.

Deferir al compilador no hace lo mismo: el compilador solo tiene una opción: FALLO.
La razón por la que tslint maneje es que a menudo necesita ser una advertencia (garabato verde vs rojo).

Los problemas de tslint no solo se pueden mostrar como advertencias, sino que también se pueden ignorar de forma aislada, mientras que los errores de compilación de mecanografiado no se pueden

Estos puntos ya han sido eliminados (vea mi último comentario y los hilos vinculados). No hay nada que le impida usar no-unused-variable como regla de TSLint en este momento. No estoy seguro de lo que intentan lograr estos comentarios de seguimiento.

@mastrauckas , ¿sigues teniendo problemas con esta regla? La --type-check ha quedado obsoleta, pero se requiere --project para habilitar las reglas basadas en la verificación de tipos.

Aparte: con TS 2.6 , puede usar // @ts-ignore para suprimir errores del compilador.

@adidahiya simplemente estaba respondiendo a los comentarios anteriores que afirman que no hay razón para tener esto como una regla de lint en lugar de una regla de compilación.

pero tienes razón, supongo que el problema relevante es con la extensión vscode, no con tslint. tbh hubo tantos problemas sobre este tema que me tomó un tiempo descubrir exactamente por qué no funciona y dónde.

agradezco la propina. Definitivamente volveré a usar la configuración del compilador tan pronto como cambiemos a 2.6

Otro punto para aquellos que afirman que esto no debería ser una regla de pelusa: las advertencias de pelusa se pueden corregir, y este es un candidato principal para eso.

Recibo la misma advertencia en el último 1.19 VS Code The 'no-unused-variable' rule requires type information con esto (ver más abajo). ¿Falta algo en mi configuración?

{
  "extends": "tslint:recommended",
  "rules": {
    "linebreak-style": [true, "LF"],
    "quotemark": [true, "single", "avoid-escape", "avoid-template"],
    "no-console": false,
    "no-unused-expression": false,
    "ordered-imports": false,
    "member-access": [true, "no-public"],
    "object-literal-sort-keys": false,
    "curly": [true, "ignore-same-line"],
    "semicolon": [true, "never"],
    "no-var-requires": false,
    "no-unused-variable": true
  }
}

Si observa el archivo Léame de VSCode 1.19, hay una nueva función para registrar esta y otras reglas como advertencias.
Para nosotros, significa:

  • eliminar "no-unused-variable" de tslint.json
  • agregue "noUnusedLocals" a nuestro tsconfig.json

Otras reglas se dejan como ejercicio para el lector ;-)

Tenga en cuenta que tslint es esta extensión, mientras que tsconfig es el comportamiento integrado de VSCode.

Opté por eliminar no-unused-variable ya que VS 1.19 parece informarlos ya.

No entiendo qué tiene que ver VSCode con esto. No es suficiente que solo VSCode los trate como advertencias, necesito que la compilación de mi servidor de desarrollo webpack no falle debido a ellos. ¿Existe un reemplazo para no-unused-variable que, independientemente de los editores particulares,

  • ser tratado como una advertencia durante el desarrollo
  • fallar compilaciones durante CI

?

@pelotom , varias personas fueron redirigidas aquí desde la extensión VSCode TSLint, por ejemplo, desde https://github.com/Microsoft/vscode-tslint/issues/219

Hasta ahora, TS no podía mostrar algunos problemas como advertencias (garabatos verdes), pero lints (ESlint, TSLint) sí podía. Entonces nos preguntamos por qué TSlint no informaría las variables no utilizadas como advertencias. Pero a partir de 1.19, TS de VSCode puede hacer estas advertencias y nos retiramos de este problema 😉

Para ser claros, también uso VSCode y también me gustaría ver estas advertencias resaltadas en el editor, pero la configuración de VSCode parece ser la capa incorrecta en la que _configurar_ la gravedad de los errores del compilador, ya que no afecta al resto de su cadena de herramientas.

Estoy de acuerdo contigo Tom, y espero que la solución se encuentre donde tanto el editor como nuestros procedimientos de compilación / CI tengan el soporte adecuado. Hasta ahora hemos visto un fuerte retroceso (aparentemente justificado) y algunos (incluyéndome a mí) tomaríamos lo que podamos, hoy, mientras mantenemos la esperanza de una solución real.

Si observa el archivo Léame de VSCode 1.19, hay una nueva función para registrar esta y otras reglas como advertencias.

@rnemec Creo que

VS Code ahora muestra problemas de estilo de código TypeScript como advertencias en lugar de errores. Esto aplica a:

La variable se declara pero nunca se usa
La propiedad se declara pero su valor nunca se lee
Código inaccesible detectado
Etiqueta no utilizada
Caer a través del caso en el interruptor
No todas las rutas de código devuelven un valor
Tratarlos como advertencias es coherente con otras herramientas, como TSLint. Estos aún se mostrarán como errores cuando ejecute tsc desde la línea de comando.

Puede deshabilitar este comportamiento configurando: "typescript.reportStyleChecksAsWarnings": false.

Entonces, esta es una solución temporal y solo funcionaría cuando se usa VSCode. Cualquier otra herramienta de compilación que use tsc directamente no compilaría el código si las advertencias se dejan allí. Tengo algunos colegas que están usando Atom, por lo que no podrán compilar el código si hice cambios e ignoré una de las advertencias. ¿Derecha?

No entiendo muy bien cómo esto resuelve nada. ¿Cómo es útil mostrar estas cosas como advertencias si el compilador aún las trata como errores?

Y si lo entiendo correctamente, la solución a largo plazo sería agregar una bandera para imponer el mismo comportamiento en tsc (haciendo que se compile con advertencias), o eliminar estas comprobaciones del compilador por completo.

--- editar ---
No leí todos los comentarios anteriores. @pelotom ya estaba haciendo lo mismo.

Si desea que las comprobaciones de pelusa tengan una gravedad diferente en el modo de desarrollo frente al modo de CI, puede hacer esto con varias configuraciones de tslint.json donde una extends la otra. # 2569 debe corregirse para que la UX aquí sea buena, de modo que pueda alternar la gravedad con solo una línea de configuración defaultSeverity : está en progreso.

@adidahiya lo que se está discutiendo es un supuesto _ reemplazo_ para la regla no-unused-variable lint, usando tsc noUnusedLocals .

@pelotom correcto, lo tsc admita todavía ese flujo de trabajo. Podría tener dos archivos tsconfig.json donde uno extiende el otro y deshabilita cada verificación del compilador "no fatal" (en este caso, noUnusedLocals , noUnusedParameters ) individualmente, sin embargo, esto no sería No le dejo ver los cheques como advertencias en su editor.

@adidahiya sí, por eso no es un reemplazo válido actualmente. Y prefiero ver no-unused-variable hecho para funcionar correctamente en VSCode que invertir más esfuerzo para que noUnusedLocals comporte más como una regla de pelusa. En mi opinión, fue un error que el compilador intentara apropiarse de este tipo de verificación en primer lugar.

Y preferiría ver la variable no no utilizada para que funcione correctamente en VSCode que invertir más esfuerzo para que noUnusedLocals se comporte más como una regla de pelusa.

Tiene sentido. Creo que este proyecto tiene como objetivo hacer eso: https://github.com/angelozerr/tslint-language-service. Puede usar reglas que requieran verificación de tipos con ese complemento.

Hablé demasiado pronto. Estamos bloqueados en https://github.com/palantir/tslint/issues/2649 para que ese complemento sea útil. En su lugar, rastrea ese problema.

@adidahiya sí, lo he estado rastreando durante bastante tiempo.

¿Alguna noticia sobre esto? ¿Estará obsoleto o no?

@ philip-firstorder usando esto solucionó el problema para mí --project tsconfig.json

tslint -c tslint.json --project tsconfig.json src/**/*.ts

no-unused-variable ahora está en desuso, vea # 3918 y # 3919

🤖 ¡Bip boop! 👉 TSLint está obsoleto 👈 ¡y debería cambiar a mecanografiado-eslint ! 🤖

🔒 Este tema se está bloqueando para evitar más discusiones innecesarias. ¡Gracias! 👋

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