O principal tempo de execução do Linter com um conjunto de regras bem escolhidas. Personalizável com suas próprias regras, processadores, formatados, configurações compartilháveis e módulos de plug -in.
Consulte os documentos para obter uma explicação detalhada das regras disponíveis, configuração e uso.
Vé
Processador oficial para componentes de arquivo único VUE (SFC). Extrai o conteúdo do script dos seus arquivos *.vue para linha.
Heimdall
Camada de compatibilidade para permitir o uso de regras e formates TSLINT dentro do tempo de execução do Wotan.
Valtýr
Faça Wotan se comportar quase como tslint. Reutilize seu tslint.json existente sem nenhuma alteração.
Bifröst
Permite que os autores de regras e formatados tslint forneçam seu pacote para o uso dentro do Wotan. Regras e formates que usam Bifröst não precisam do Heimdall para funcionar corretamente.
Ymir
Fornece tipos principais para regras personalizadas e autores de plug -in.
Mímir
Contém todas as regras principais, formates e predefinições de configuração.
Mithotyn
Plugin de Languageservice para TypeScript. Fornece um linhagem no editor em tempo real enquanto você digita.
Documentação adicional
Entendendo a API do TypeScript
REGRAS DE ESCRITÓRIO
Regras de teste
Usando regras locais
Escrevendo configurações compartilháveis
Usando a API
Receitas
Linering Vue Arquivos com regras TSLINT
Substituição para tslint --type-check
Detectar variáveis não utilizadas
O que se trata tudo?
O que há com esses nomes?
Mitologia nórdica:
Fimbullinter vem de Fimbulwinter, o terrível inverno de três anos que durou os eventos de Ragnarök. 'Fimbul' significa 'o grande', 'Linter' é uma ferramenta que detecta e avisa sobre certos padrões de codificação.
Wotan é um dos muitos nomes de Odin, o primeiro-papo. Você também pode conhecê -lo chamado Woden, Wodan, Wensley, etc. Woden é um deus sacrificial, sedento de sangue e cruel. Ele está constantemente lutando pela sabedoria. De seu trono, ele pode ver tudo nos nove mundos acontecendo.
Vé é o mais novo dos três incomoda Woden, Vili e Vé, que juntos mataram o gigante Ymir e criaram os nove mundos a partir de seu corpo.
Para o primeiro casal humano, pergunte e embla, Odin deu alma e vida; Vili deu inteligência (inteligência) e senso de toque; E Vé deu semblante (aparência, expressão facial), fala, audição e visão.
Heimdall (também conhecido como Heimdallr), localizado onde a ponte arco -íris queimada Bifröst encontra o céu, vigia o início de Ragnarök.
Bifröst é a ponte arco -íris ardente que conecta o mundo dos humanos ao reino dos deuses.
Valtýr , de "Valr" (os mortos, mortos em batalha) e "týr" (Deus), significa Deus dos mortos e é frequentemente usado para se referir a Odin.
Ymir é o gigante de cujo corpo o mundo inteiro foi criado. Ele é o ancestral de todo Jötnar.
Mímir ("o lembrete, o sábio") conhecido por seu conhecimento e sabedoria. O Deus Odin carrega a cabeça de Mímir e recita conhecimentos e aconselhamento secretos a Ele.
Mithotyn (na verdade "Mitoðinn", que significa "dispensador do destino") introduz regras onde não havia. Preenche o lugar de Odin durante suas viagens a terras estrangeiras.
Por que ainda outro linhador?
Este tenta evitar decisões de design de outros linheiros que acabaram sendo problemáticos:
Evite conflitos de nome, prefixando os nomes de regras, dependendo do pacote de onde eles vêm.
O TSLINT coloca todas as regras em um espaço de nome global e as procura em todos os diretórios de regras disponíveis. A ordem dos diretórios é importante, enquanto as regras do núcleo substituem precedência.
Eslint permite um diretório de regras local como sinalizador da CLI. As regras nesse diretório podem substituir as regras principais.
As dependências dos arquivos de configuração são resolvidas em relação a esse arquivo.
O TSLINT já faz isso.
Eslint não suporta isso.
Nenhuma distinção entre configurações compartilháveis e plugins. De fato, ambos são apenas configurações extensíveis que, opcionalmente, podem fornecer diretórios de regras, configurações, regras e processadores.
O TSLINT permite que você escolha entre extends e rulesDirectory . O diretório de regras de um pacote é um detalhe da implementação e não deve fazer parte da configuração do usuário.
O ESLint lida com configurações e plugins bem diferentes. Na verdade, eles tentaram depreciar as configurações compartilháveis em favor dos plugins.
Carregamento preguiçoso de regras para reduzir o tempo de inicialização.
O TSLINT já faz isso.
Eslint espera que os plugins forneçam as regras como objetos já carregados. Isso causa muita sobrecarga se você usar apenas algumas regras de um grande pacote.
Armazenamento em cache de acesso e configuração do sistema de arquivos. Como o cache é um serviço de DI, os usuários da API podem limpar o cache quando necessário.
Suporte para processadores desde o início. Ativando o revestimento de arquivos *.vue e muito mais.
Aliases para regras com configuração. Pode ser usado para tratar regras como no-resticted-syntax da ESLint como regras nomeadas distintas para cada opção de configuração.
Toda a API é alimentada por um contêiner DI. Isso facilita a injeção de um serviço diferente. Você pode até usar plugins através da CLI para injetar serviços diferentes.
Arquivo de configuração "Global" (além de .wotanrc.yaml ) para padrões de CLI e configuração do plug -in: .fimbullinter.yaml . Este arquivo também pode ser usado pelos plugins do editor, portanto, não há necessidade de duplicar a configuração comum.
Eslint não tem esse arquivo e se recusou a adicionar um no futuro. Ferramentas como standard ou xo não precisariam existir se você precisasse criar um arquivo de configuração com os padrões de CLI.
O TSLINT Startet para enchê -lo em seu tslint.json , o que leva a usuários confusos.
Relate os comentários de habilitação e desativação não utilizados e redundantes (ou partes dela) com --report-useless-directives .
Eslint relata apenas os comentários desativados não utilizados. Ele apenas relata comentários completamente não utilizados. Comentários redundantes não são relatados e também permitem comentários para regras inexistentes.
O TSLINT não suporta isso.
Diferenças para tslint
Para estender um plug-in ou configuração compartilhável, use extends: plugin-name . O nome será resolvido de acordo com o algoritmo de resolução do módulo do Node em relação ao arquivo de configuração.
Para usar as regras mantidas dentro do seu projeto, use rulesDirectory: {"my-prefix": "./path/to/rules"} e configure-as como my-prefix/rule-one: "error" . O diretório de regras é um caminho em relação ao arquivo de configuração.
Substituições: você pode substituir a cofiguração principal especificando uma ou mais substituições. Se o nome do arquivo corresponder ao padrão global da substituição, todas as configurações fornecidas por essa substituição serão aplicadas. As substituições são processadas em ordem, substituições posteriores substituem as configurações de substituições anteriores.
Os padrões correspondem em relação ao arquivo de configuração em que são especificados.
Os padrões sem uma barra são correspondidos apenas com o nome de base de cada arquivo.
Para limitar uma correspondência com o diretório atual, prefixo o padrão com ./ .
Padrões negados podem ser usados para subtrair as correspondências dos padrões anteriores.
linterOptions.exclude -> exclude
Excluir não são substituídos ao estender uma configuração.
A correspondência de padrões segue as mesmas regras que substitui (veja acima).
JSON5 Suporte para arquivos de configuração.
Configurações independentes de regras que as regras e processadores podem captar.
Processadores, até suporta --project .
Aliases, veja acima
Uma abordagem sã e segura para a fixação:
Não corrige arquivos com erros de sintaxe.
Exclui substituições sobrepostas para impedir a destruição de seu código.
Executa um número configurável de iterações por arquivo para aplicar alterações conflitantes na próxima iteração.
Paradas se as correções introduziriam erros de sintaxe.
Corrigir com --projectnão cria todo o programa do zero, o que o torna incrivelmente rápido.
Teste
Os testes são configurados em arquivos JSON que podem configurar tudo o que você pode especificar, embora a CLI
Os arquivos de teste não contêm marcação de erro. Isso evita erros de sintaxe e facilita a manutenção. Os resultados dos fiapos e o conteúdo fixo são armazenados em arquivos de linha de base separados.
O mesmo código pode ser testado com configurações diferentes.
Suporta referências do projeto TypeScript.
Carrega valores padrão para opções de CLI de .fimbullinter.yaml .
Não usa informações de tipo em arquivos JavaScript sem controle ( // @ts-nocheck ou "checkJs": false ).
Relatórios não utilizados e redundantes Ativam e desativam comentários com --report-useless-directives .
Ambientes suportados
Este projeto é executado em todas as versões ativamente suportadas do Node.JS.
Este projeto suporta oficialmente a mais recente versão estável do TypeScript. Até a redação, isso é 3,0 - 3.2. Ele deve funcionar com as compilações noturnas do TypeScript ( typescript@next ), mas não há garantia.
As regras personalizadas devem pelo menos usar o ES6 para ter suporte para classes nativas. Caso contrário, você enfrenta problemas ao tentar estender as classes exportadas de qualquer um dos pacotes.
Versão semântica (Política de Semver)
️ A política a seguir se aplica apenas para os lançamentos de 1.x e seguintes. Cada liberação na faixa 0.x é considerada experimental. Pode e haverá mudanças na API sem depreciação.
Em teoria, todas as mudanças em uma regra podem quebrar os usuários e podem ser considerados uma mudança de ruptura. Para evitar lançar uma nova versão principal para cada correção de bugs, temos diretrizes ligeiramente diferentes, conforme descrito abaixo.
PrereLeases (construções noturnas)
não são garantidos para serem estáveis
Tagged como next no npm para que você possa instalar @fimbul/wotan@next
Contém as últimas alterações destinadas à próxima versão
x.0.0-dev* contém todas as alterações, incluindo quebra para a próxima versão principal
xy0-dev* contém todas as alterações para a próxima versão menor
Não há prerelares para versões de patch
Patch lançamentos
correntes falhas
FILE REGRESSIONIONIONES
Refattorings da funcionalidade interna que não mudam o comportamento do usuário
Pequenos lançamentos
Adiciona novas regras, opções de regras, formatados, processadores, APIs
As regras podem adicionar novos cheques que podem levar a novas descobertas
Novas regras e opções estão ativadas em wotan:latest
As regras podem mudar suas mensagens de localização
Os formatados destinados ao consumo humano (por exemplo, stylish ) podem alterar sua saída
regras, opções de regras, formates, processadores e APIs podem ser preteridos
Novas opções de configuração podem ser adicionadas aos arquivos de configuração
Principais lançamentos
Contém Breaking API mudanças
Remove regras, opções, formates, etc.
Os formatados destinados ao consumo de máquina (por exemplo, json ou tap ) podem alterar sua saída
wotan:recommended é atualizado para o conteúdo de wotan:latest
Cronograma de lançamento
Atualmente, não há cronograma de liberação fixa. As construções noturnas são publicadas todas as noites, se houver mudanças no mestre. As versões de patch são publicadas assim que os bugs são identificados e corrigidos. Os lançamentos menores são publicados a cada semana ou duas, se houver alterações no mestre. Os principais lançamentos são publicados uma vez que as mudanças de ruptura o suficiente forem acumuladas.
