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": "^_"}]
}
}
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)
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.
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
ynoUnusedParameters
encompilerOptions
no es exactamente lo mismo queno-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
Comentario más útil
Definir
noUnusedLocals
ynoUnusedParameters
encompilerOptions
no es exactamente lo mismo queno-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 😞