Tslint: Solicitação de recurso: permitir a exclusão de arquivos para uma regra específica

Por que você simplesmente não usa:

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

Isso não funciona?

Isso poderia realmente ser usado para fazer funcionar, mas eu apresentei esta solicitação de recurso para evitar modificar o gerador de TypeScript (ou adicionar complexidade ao processo de geração, acrescentando arquivos gerados com dicas tslint).
O uso de curingas também pode ser benéfico para aplicar declarativamente certas regras apenas a tipos específicos de fontes (main / unitTests / e2eTests) da configuração tslint, não de cada arquivo individualmente.

O que você acha?

Se você não quiser colocar comentários no arquivo, simplesmente não passe o arquivo para tslint para linting, não?

Parece muito pesado adicionar outras opções em outro lugar quando há pelo menos dois meios de alcançar a exclusão (parcial) de arquivo

Se você não quiser colocar comentários no arquivo, simplesmente não passe o arquivo para tslint para linting, não?

Isso é exatamente o que eu fiz, mas agora nenhuma das regras é verificada em relação aos arquivos excluídos.

Parece muito pesado adicionar outras opções em outro lugar quando há pelo menos dois meios de alcançar a exclusão (parcial) de arquivo

Sim, foi isso que antecipei como resposta;) Também tive algumas dúvidas - pelo menos sobre a implementação (que tentei manter o mais simples possível).

Na realidade, se isso fosse implementado, seria benéfico se você pudesse definir constantes para incluir e excluir padrões, para que você não tivesse que copiar e colar o mesmo padrão de inclusão / exclusão para todas as regras onde deseja filtrar os mesmos arquivos ... Achei que não seria razoável complicar o exemplo, mas eu tinha um pouco disso em 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"],
        ...
    }
}

mas isso tornaria o arquivo de configuração mais difícil de analisar. Isso me levou a pensar em suportar arquivos js para configuração, além de arquivos json. Por exemplo:

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"],
        ...
    }
}

Usar arquivos JavaScript com módulos (como o gulp faz) tem outro benefício - permite comentários e não é tão rígido quanto a vírgulas após o último elemento no array ou propriedade no objeto.

@atsu85 problema interessante, mas como @myitcv indicou, estou relutante em introduzir listas de arquivos / globs em tslint.json por causa da complexidade / desordem adicional no arquivo de configuração. Eu concordo que o TSLint deve aceitar .js arquivos para configuração, além de simplesmente .json arquivos. Acho que isso o ajudaria a resolver o caso de uso - você poderia configurar duas tarefas de construção tslint (uma para suas fontes regulares, uma para fontes geradas) e desabilitar programaticamente a regra class-name em uma deles no mesmo arquivo tslintConfig.js .

Arquivado nº 1065 por oferecer suporte a .js arquivos de configuração

Muito bem, encerrarei este problema apenas em favor dos arquivos de configuração js

Tenho um caso de uso para isso que pode fazer sentido. Tenho arquivos de teste (* .spec.ts) com os quais desejo compartilhar a maioria das minhas regras TSLint do Typescript, pois as boas práticas de codificação também se aplicam aos meus testes.

No entanto, estou testando algumas constantes que são configuradas para a regra dos 'números mágicos', de modo a não ter 5 em meu código:
(Foo.substr(0,5);
mas certifique-se de que é um const
(Foo.substr(0,CONSTANT.FIVE);

Como tal, meu caso de teste para meu const que está incluído em um arquivo comum, tem um teste para garantir que const FIVE = 5 esteja sempre definido. O teste, então, expect(CONSTANTS.FIVE).toBe(5); falha na verificação do TSLint, pois o número mágico é usado no teste. Embora eu não teste todas as constantes dessa maneira, quero verificar essas configurações numéricas para garantir que não mudem, pois espera-se que permaneçam com o tamanho específico.

Eu poderia usar duas configurações de TSLint diferentes, mas eu realmente quero evitar que elas fiquem fora de sincronia, ou ao adicionar uma nova regra, ter que fazer isso em vários lugares.

Posso fazer o / * tslint: disable : no-magic-numbers * / para aquele arquivo para esses testes específicos que funcionam para mim, mas talvez em alguns outros casos no arquivo de testes uma regra comum precise ser uma exceção, e em vez de atualizar cada * .spec.ts, o padrão global para a regra funcionaria?

Eu tenho o caso de uso semelhante a @Chowarmaan.

Eu tenho arquivos de teste *.test.ts nos quais uso dependências de desenvolvimento, por exemplo, enzyme .
Em tslint.json eu tenho a regra no-implicit-dependencies habilitada e desejo desabilitar esta regra apenas para *.test.ts . Esses arquivos de teste não estão todos na mesma pasta, então agora eu tenho que colocar:

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

no início de cada arquivo de teste, o que é irritante

Este é um problema semelhante que eu encontrei, bem como @RomanGotsiy, onde você pode adicionar desabilitações no topo dos arquivos de teste, mas torna-se complicado para cada arquivo. Os arquivos de exclusão seriam úteis, pois você pode excluir regras para determinados arquivos de padrão (arquivos de teste, * .spec.ts) e ter um arquivo de configuração limpo que também permite que você simplesmente habilite mais regras conforme necessário e permita seus testes para usá-los também. Talvez a lista de arquivos de exclusão inclua apenas as regras que você deseja desabilitar, em vez de adicionar a exclusão de arquivos a cada regra?

Esse. 100%. Tendo este problema com um monorepo em que as dependências de teste são listadas no espaço de trabalho, tslint está reclamando de no-implicit-dependencies . Deve ser feito com um único arquivo de configuração para que o IDE linting ainda funcione

Acho que esse problema também está relacionado ao # 3447

Vou acrescentar a este tópico obsoleto também. Estou em processo de implementação de uma loja NgRx em meu projeto Angular. O build AOT está gritando comigo quando exporto uma referência const para uma função ...

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

Apresentando um erro de Function expressions are not supported in decorators in 'reducers' . O problema surge devido às nossas regras de linting. Habilitamos especificamente a regra only-arrow-functions todo o projeto ... seria maravilhoso adicionar a correspondência de padrões na exclusão para dizer excluir arquivos de *.reducer.ts como um exemplo para esta regra específica, mas permitir para permanecer intacto para todos os outros arquivos.

Do jeito que está, adicionar esta linha ao início do arquivo para cada arquivo redutor é complicado. Parece que deveria haver uma maneira melhor.

Necrobumping isso também. Estou tentando adicionar tslint-microsoft-contrib a um projeto Vue e um monte de suas bombas de regras em arquivos .vue; isso pode ser uma solução útil para problemas como esse, antes que os autores da regra resolvam esses bugs - se quiserem. Como está, adicionar um comentário para desativar um monte de regras em absolutamente todos os arquivos Vue que escrevo é realmente complicado. Também faz sentido ser um pouco menos estrito no código da IU ou lidar com expressões idiomáticas do framework, por exemplo, o uso de exportações padrão