Tslint: Solicitud de función: permitir la exclusión de archivos para una regla específica

¿Por qué no usas simplemente:

/* tslint:disable:class-name */
// your generated file here

¿No funciona esto?

De hecho, eso podría usarse para que funcione, pero presenté esta solicitud de función para evitar modificar el generador de TypeScript (o agregar complejidad al proceso de generación, anteponiendo los archivos generados con sugerencias tslint).
El uso de comodines también podría ser beneficioso para aplicar de forma declarativa ciertas reglas solo a tipos específicos de fuentes (main / unitTests / e2eTests) de tslint config, no de cada archivo individualmente.

¿Qué piensas?

Si no desea poner comentarios en el archivo, simplemente no pase el archivo a tslint para que lo mezclen, ¿no?

Se siente demasiado pesado agregar más opciones en otro lugar cuando hay al menos dos formas de lograr la exclusión (parcial) de archivos

Si no desea poner comentarios en el archivo, simplemente no pase el archivo a tslint para que lo guarde, ¿no?

Eso es exactamente lo que hice, pero ahora ninguna de las reglas se compara con los archivos excluidos.

Se siente demasiado pesado agregar más opciones en otro lugar cuando hay al menos dos formas de lograr la exclusión (parcial) de archivos

Sí, eso es lo que anticipé como respuesta;) También tenía algunas dudas, al menos sobre la implementación (que intenté mantener lo más simple posible).

En realidad, si esto se implementara, sería beneficioso, si pudiera definir constantes para incluir y excluir patrones, por lo que no tiene que copiar y pegar el mismo patrón de inclusión / exclusión en todas las reglas donde desea filtrar los mismos archivos ... Pensé que podría no ser razonable hacer el ejemplo más complicado, pero tenía algo así en mente:

{
    "constants": {
        "generatedFilesGlob": "**/generated.ts",
        "someOtherConstant": "some other value, that could be reused",
        ...
    },
    "rules": {
        "class-name": true,
        "some-otherrule": [ true, "arg1", "arg2", "arg3"],
        "rule-with-exclude": [ {"exclude": "generatedFilesGlob"}, "arg1", "arg2", "arg3"],
        ...
    }
}

pero eso haría que el archivo de configuración fuera más difícil de analizar. Eso me llevó a pensar en admitir archivos js para la configuración, además de los archivos json. Por ejemplo:

const generatedFilesGlob = "**/generated.ts";
const allExceptGenerated = {exclude: generatedFilesGlob};
module.exports = {
    "rules": {
        "class-name": true,
        "some-otherrule": [ true, "arg1", "arg2", "arg3"],
        "rule-with-exclude": [ allExceptGenerated , "arg1", "arg2", "arg3"],
        "another-rule-with-the-same-exclude-pattern": [ allExceptGenerated , "arg1", "arg2", "arg3"],
        ...
    }
}

El uso de archivos JavaScript con módulos (como lo hace gulp) tiene otro beneficio: permite comentar y no es tan estricto con las comas después del último elemento en la matriz o propiedad en el objeto.

@ atsu85 problema interesante, pero como @myitcv indicó, soy reacio a introducir listas de archivos / globs en tslint.json debido a la complejidad / desorden adicional en el archivo de configuración. Estoy de acuerdo en que TSLint debería aceptar archivos .js para la configuración además de simplemente archivos .json . Creo que eso lo ayudaría a abordar el caso de uso: podría configurar dos tslint tareas de compilación (una para sus fuentes regulares, otra para fuentes generadas) y deshabilitar programáticamente la regla class-name en una de ellos en el mismo archivo tslintConfig.js .

Archivado # 1065 para admitir archivos de configuración .js

Muy bien, cerraré este problema a favor de solo los archivos de configuración js

Tengo un caso de uso para esto que podría tener sentido. Tengo archivos de prueba (* .spec.ts) con los que quiero compartir la mayoría de mis reglas de Typecript TSLint, ya que las buenas prácticas de codificación también se aplican a mis pruebas.

Sin embargo, estoy probando algunas constantes que están configuradas para la regla de los 'números mágicos', para no tener 5 en mi código:
(Foo.substr(0,5);
pero asegúrate de que sea constante
(Foo.substr(0,CONSTANT.FIVE);

Como tal, mi caso de prueba para mi const que se incluye desde un archivo común, tiene una prueba para asegurar que la const FIVE = 5 siempre esté configurada. Luego, la prueba expect(CONSTANTS.FIVE).toBe(5); falla en la verificación de TSLint ya que el número mágico se usa en la prueba. Si bien no pruebo todas las constantes de esta manera, quiero verificar estas configuraciones numéricas para asegurarme de que no cambien, ya que se espera que sigan teniendo el tamaño específico.

Podría usar dos configuraciones TSLint diferentes, pero realmente quiero evitar que se desincronicen o, al agregar una nueva regla, tener que hacerlo en varios lugares.

Puedo hacer el / * tslint: disable : no-magic-numbers * / para el único archivo para estas pruebas específicas que funciona para mí, pero tal vez en algunos otros casos en el archivo de pruebas, una regla común puede necesitar ser una excepción, y en lugar de actualizar cada * .spec.ts, ¿funcionaría el patrón global de la regla?

Tengo un caso de uso similar al de @Chowarmaan.

Tengo archivos de prueba *.test.ts en los que uso dependencias de desarrollo, por ejemplo, enzyme .
En tslint.json tengo la regla no-implicit-dependencies habilitada y quiero deshabilitar esta regla solo por *.test.ts . Esos archivos de prueba no están todos en la misma carpeta, así que ahora tengo que poner:

/* tslint:disable:no-implicit-dependencies */

al principio en cada archivo de prueba que es molesto

Este es un problema similar con el que me encuentro, así como @RomanGotsiy, donde puede agregar deshabilitaciones en la parte superior de los archivos de prueba, pero se vuelve engorroso para cada archivo. Los archivos de exclusión serían útiles ya que podría excluir reglas para ciertos archivos de patrones (archivos de prueba, * .spec.ts) y tener un archivo de configuración limpio que también le permite simplemente habilitar más reglas según las necesite y permitir sus pruebas para usarlos también. ¿Quizás la lista de archivos de exclusión incluiría las reglas que desea deshabilitar, en lugar de agregar la exclusión de archivos a cada regla?

Esta. 100%. Tener este problema con un monorepo donde las dependencias de prueba se enumeran en el espacio de trabajo, por lo que tslint está llorando por no-implicit-dependencies . Tiene que hacerse con un único archivo de configuración para que el linting IDE siga funcionando

Creo que este problema también está relacionado con # 3447

También voy a agregar a este hilo obsoleto. Estoy en el proceso de implementar una tienda NgRx en mi proyecto Angular. AOT build me grita cuando exporto una referencia constante a una función ...

export const reducer = ( state = initialState, action: CurrentAction): CurrentState => {...}

Dándome un error Function expressions are not supported in decorators in 'reducers' . El problema surge debido a nuestras reglas de deshilachado. Hemos habilitado específicamente la regla only-arrow-functions todo el proyecto ... sería maravilloso agregar la coincidencia de patrones en la exclusión para decir excluir archivos de *.reducer.ts como ejemplo de esta regla específica pero permitir que permanezca intacto para todos los demás archivos.

Tal como está, agregar esta línea al principio del archivo para cada archivo reductor es engorroso. Parece que debería haber una mejor manera.

Necrobumping esto también. Estoy tratando de agregar tslint-microsoft-contrib a un proyecto de Vue y un montón de sus reglas bombardean en archivos .vue; esta podría ser una solución útil para problemas como este antes de que los autores de las reglas solucionen esos errores, si es que alguna vez lo deciden. Tal como está, agregar un comentario para deshabilitar un montón de reglas en absolutamente todos los archivos de Vue que escribo es realmente engorroso. También tiene sentido ser un poco menos estricto en el código de la interfaz de usuario o lidiar con modismos del marco, por ejemplo, el uso de exportaciones predeterminadas