Jshint: O recuo de tabulação quebra várias regras

Obrigado pelo relatório! O problema decorre da linha 1610 de lex.js :

this.input = this.input.replace(/\t/g, state.tab);

Isso parece bastante fundamental para quantas das regras de linting relacionadas ao estilo são implementadas. Eles estão obsoletos há algum tempo, mas ainda não estamos prontos para passar para uma nova versão principal. Então, nesse meio tempo, precisaremos projetar uma solução que preserve esse comportamento.

Meu pensamento inicial é rastrear esse "deslocamento efetivo" como uma nova propriedade do objeto token chamado column . Isso pode ser usado para os avisos relacionados ao estilo. Então, o atributo character pode ser reimplementado para descrever o deslocamento de caractere "verdadeiro", onde cada ponto de código (tab ou outro) incrementa a contagem exatamente em 1. Esse valor seria usado para emitir avisos. Os plugins do Reporter estariam então no controle de como eles renderiam o caractere de tabulação e poderiam interpretar o número da "coluna" relatado de acordo.

Isso soa bem para você, @Arcanemagus?

Isso soa perfeito para mim, pelo menos na superfície, sem nenhum conhecimento real dos componentes internos do JSHint 😛. Idealmente, eu só preciso de algum método para obter a contagem verdadeira de colunas (onde cada ponto de código conta como uma coluna).

Isso ficou oculto por um tempo devido a esse aviso ser essencialmente ignorado devido a uma solução alternativa para algum bug antigo do analisador com um erro semi-comum. Quando eu reimplementei o aviso para os usuários de uma maneira muito mais agradável, eu acidentalmente os _ocultei_ e recentemente o consertei, tornando isso visível novamente.

Parece que W030 , W033 e W009 também são afetados. Pela sua descrição, estou assumindo que _todas_ as regras são afetadas?

Também estou enfrentando esse problema e consigo replicar em erros e avisos. O tipo de regra/erro não parece importar.

Aqui está um exemplo de jshint tentando me avisar que meu '==' deve ser '==='. Observe a localização errônea do sublinhado laranja:

Espero que isso confirme seus pensamentos sobre o problema.

Eu tenho algum tempo para fazer algumas escavações hoje, e acredito que definir a opção indent para 1 produzirá os resultados desejados.

@Arcanemagus Você pode substituir o valor da opção indent para seus consumidores? Se isso for possível, prefiro fazer isso, pois não tenho certeza de como alterar o valor padrão no próprio JSHint poderia afetar seus consumidores.

Hmmm, atualmente este projeto usa a interface CLI que parece. É possível reescrevê-lo para usar a API Node.js, o que tornaria isso possível.

• Forçar o indent mudaria os resultados que os consumidores veem? O objetivo desse pacote é ser o mais próximo possível da execução do jshint , mas obtendo os resultados integrados no editor.
• A API JSHint tem um método oculto para obter a configuração de um arquivo ou isso precisaria ser implementado? A documentação atual não mostra tal função.

Que tal adicionar um argumento de linha de comando que permita substituir valores da configuração?
Algo assim é comum em ferramentas como -g no nginx, -o no ssh, -c no git e muitos mais, eu acho.

$ jshint -o "indent = 1" -o "-W034 = true" -o "globals.require = false" -o "globals.$ = null"

Alguém sabe em que versão isso foi introduzido? 2.9.5?

Pelo menos então poderíamos fazer o downgrade no momento como temporário. consertar.

@jaredatch De volta a https://github.com/AtomLinter/linter-jshint/pull/386 (lançado na v3.1.0 de linter-jshint ) todas as soluções alternativas para o relatório de pontos de bugs do JSHint foram removidas. O ponto principal dessa verificação é encontrar bugs como esse, onde o linter está relatando pontos inválidos para que possa ser relatado e corrigido para _todos_ usando o linter. (Afinal, se você não pode confiar no linter para fornecer dados precisos, por que usá-lo?)

Pode haver um "ponto ideal" antes deste bug de guia ser introduzido e depois dos principais bugs do analisador que fizeram com que essas soluções alternativas fossem implementadas em primeiro lugar.

@Arcanemagus pegou , realmente aprecio o insight. Continue com o ótimo trabalho 👍

Se você tiver uma ideia de mensagem melhor / mais útil sobre como linter-jshint relata esses pontos inválidos, sinta-se à vontade para registrar um problema / enviar um PR por lá 😉.

POR FAVOR, TODAS AS SUAS SOLUÇÕES SUGARAM, EU PASSEI AS ÚLTIMAS 5 HORAS TENTANDO LINTAR UMA PORRA DE UM ARQUIVO JAVASCRIPT, É PORRA DE 2017 POR QUE ESTOU TENDO ESSE PROBLEMA O ÁTOMO É A PORRA DA MINHA VIDA, CONSERTE-SE, SEU ESTÚPIDO

E QUE PORRA NÃO USA TABS PARA RECUAR LITERALMENTE POR QUE VOCÊ LANÇARIA UM PACOTE QUEBRADO PARA OS MILHÕES QUE LINT JS???????

Quem não usa pontos literalmente com por que você libera esse inglês quebrado para os milhões que o inglês é?

Oh. E caracteres em maiúsculas vão no início de uma frase. Não em todos os lugares.

/Troll (sry, não pude evitar)

Bem, acho que a solução será desativar isso por enquanto ...
Quem precisa de linters afinal?

@jugglinmike Você pode responder às perguntas em https://github.com/jshint/jshint/issues/3151#issuecomment -312512856?

Eu tenho 20 problemas exclusivos abertos para diferentes casos disso sendo acionado, pois parece que corrigir isso aqui levará um tempo.

Esse problema escapou do meu radar; Sinto muito por isso, @Arcanemagus. Infelizmente, acho que não serei capaz de dar a atenção que merece até este fim de semana. Será que isso funciona para você?

@jugglinmike Claro 😉

Eu coloquei algumas verificações para problemas existentes, então, na maioria das vezes, as pessoas estão sendo filtradas para os problemas já abertos apontando aqui.

@cobexer Eu gosto dessa ideia porque além de nos dar um caminho a seguir,
pode ser útil para pessoas em outros contextos. Dito isso, que eu saiba há
nunca houve um pedido para esse tipo de funcionalidade, e estou relutante em
comprometer-se a qualquer novo recurso apenas porque parece bom. E há razão para
desencorajar esse recurso em particular: entre arquivos "rc", in-line
configuração e a API Node.js, os usuários já tropeçam quando querem
para entender por que uma determinada opção está habilitada. Adicionando outro vetor para configuração
gestão tenderia a agravar este problema.

Eu acho que a solução mais viável aqui é baseada no meu anteriorproposta .
No entanto, temos que considerar a propriedade character como API pública - o Atom
O plugin Editor é construído sobre ele, afinal. Então, em vez de modificar isso
propriedade e definindo uma nova que tenha a semântica da atual, acho
precisamos deixar character como está e expor os dados solicitados em um novo
nome da propriedade.

Comecei a trabalhar no novo recurso neste fim de semana. Eu quero evitar regressões em
todos os custos, por isso precisamos estender os testes do projeto para afirmar consistentemente a
número de caractere esperado. Quando comecei a fazer isso, encontrei deficiências no
conjunto de testes que precisam ser abordados primeiro. gh-3174 é o primeiro passo para
esse objetivo.

Tudo isso para dizer: parece que isso pode levar algum tempo. @Arcanemagus eu sei
você está suportando o peso deste bug, e eu aprecio você tomar isso como um
oportunidade de ver o JSHint melhorado. Eu também gosto que você está interessado em
evitando qualquer solução que não seja transparente para seus usuários. No curto
prazo, você teve alguma sorte ao recomendar que os usuários definam a opção indent para 1 ?
Não é o ideal, mas isso deve resolver o problema de curto prazo de uma maneira
que continuará a funcionar mesmo depois de corrigirmos isso.

@Arcanemagus Eu sei que você está suportando o peso desse bug, e eu aprecio você tomar isso como um
oportunidade de ver o JSHint melhorado.

Toda a razão pela qual eu adicionei a verificação à biblioteca genérica usada pela maioria dos provedores de Linter para Atom é para que bugs como esse possam ser capturados nos linters de origem e relatados / corrigidos 😉. Na verdade, isso teria sido detectado antes, mas havia uma verificação em linter-jshint que basicamente ocultava todos os erros de pontos inválidos de _way_ quando o analisador falhou completamente na maioria dos documentos e não tínhamos uma boa maneira de relatar isso aos usuários ou de desduplicação de relatórios de problemas. Agora que eles foram descobertos, removi esse cheque e aqui estamos 😛.

Também gosto que você esteja interessado em evitar qualquer solução que não seja transparente para seus usuários.

Na verdade, uma solução transparente para esse problema em particular seria boa, só não sei se forçar a configuração indent para 1 mudaria os resultados que eles estão vendo em comparação com o que eles obteriam executando jshint eles mesmos.

No curto prazo, você teve alguma sorte em recomendar que os usuários definam a opção de recuo como 1?

Isso é... uma excelente ideia que eu realmente não tinha pensado em postar nessas edições. Farei questão de mencionar isso nas questões mais comentadas!

Ah, sim, definir a propriedade 'indent' como 1 no .jshintrc é uma excelente solução alternativa. Eu gostaria de saber disso antes. Eu já tenho um .jshintrc porque jshint não é padrão para es6, então isso é simples de adicionar. 👍

Fico feliz em ouvir isso, @tustin2121!

Atualização: ainda estou trabalhando para reforçar o conjunto de testes JSHint para evitar regressões. O mais recente nesse esforço é o gh-3176.

Alguma atualização sobre este assunto?

Parece que temos pelo menos 40 regras diferentes afetadas por esse bug agora 😛.

Qualquer atualização sobre isso, faz alguns meses que estou tendo esses erros, me deixando louco :)

Olá @xcrap! Acabei de verificar o tópico de comentários, e parece que ninguém postou nenhuma atualização. A boa notícia é que o JSHint é um projeto de código aberto, então você pode ajudar a corrigir o problema se estiver causando estresse! Gostaria de dar uma mão? Eu ficaria feliz em aconselhá-lo.

@jugglinmike eu desejo! Eu sempre tento em projetos pequenos, mas minhas habilidades em js são super básicas e limitadas :)

Eu coloquei uma recompensa de $ 50 neste bug, outros podem contribuir para aumentar a recompensa através deste link: https://www.bountysource.com/issues/46533252-tab-indentation-breaks-multiple-rules

Puxar o fork do @tzvipm localmente e reconstruir o jshint funcionou para corrigir o problema para mim se mais alguém estiver se deparando com isso:

git clone https://github.com/tzvipm/jshint
git remote add upstream [email protected]:jshint/jshint.git
git fetch upstream
git stash
git merge upstream/master
git mergetool --tool=opendiff
npm run build