Jshint: Desabilitando o aviso para W100 não funcionando em 2.9.3

Obrigado pelo relatório! Isso sim é uma regressão.

Não que isso ajude muito, mas parece que a nova versão trouxe à tona um bug existente anteriormente - no processo de redução da entrada que você compartilhou, também pude experimentar esse problema na versão 2.9.2.

Eu preciso me afastar um pouco, mas espero ter um patch pronto esta noite (EST).

Aqui está a história:

Ao encontrar um caractere de parêntese aberto ( ( ) em uma expressão
posição, um analisador JavaScript compatível com ES2015 como o JSHint tem que determinar
se ele marca o início de um operador de agrupamento ou uma função de seta.

O JSHint faz isso tokenizando toda a entrada que segue até encontrar um
caractere de parêntese de fechamento "correspondente" ( ) ). Nesse momento, pode fazer um
determinação sobre a natureza da produção em questão - se for seguido
pelo token => , é uma função de seta; caso contrário, é um operador de agrupamento.

Enquanto está olhando para frente, ele não aplica as diretivas em linha que encontra
como -W100 . No entanto, o lexer é responsável por emitir certos linting
erros _incluindo_ W100 . Assim que o JSHint começar a "olhar para frente", seu
o comportamento em resposta a esses personagens potencialmente perigosos está "bloqueado".
(Isso sugere uma correção de curto prazo para quem sofre dessa regressão: desative
W100 antes do IIFE. Não é o ideal, eu sei, mas observe que a relevância dissoaviso é contestado .)

Essa regressão surgiu por causa de um patch aparentemente não relacionado: gh-3003.
Anteriormente, a antecipação seria cancelada se um token de ponto e vírgula fosse
encontrado, como em:

(function() {
;//<-- lookahead ends at this semicolon token
}());

... no entanto, descobriu-se que era uma heurística inválida porque a função de seta
parâmetros podem conter esse token:

(x = function() {
;//<-- lookahead should *not* end at this semicolon token
}) => x;

Então nós a removemos para reconhecer corretamente as funções de seta nesses casos.

Com isso em mente, o caso de teste totalmente reduzido pode ser um pouco mais claro (que
é um caractere \u200f não imprimível na string literal):

(function() {
    ;

    /*jshint -W100 */
    "‏";
})();

Antes do gh-3003 (por exemplo, JSHint na versão 2.9.2), o ponto e vírgula parava o
lookahead, e o caractere não imprimível não seria lexed até _depois_ do
A diretiva JSHint foi aplicada. Com a correção aplicada, JSHint lexes o caractere
_antes_ de aplicar a diretiva e passa a avisar.

Isso também demonstra como o problema fundamental existe mesmo no JSHint 2.9.2.
A entrada a seguir aciona incorretamente um aviso mesmo nessa versão do
JSHint:

(function() {
    /*jshint -W100 */
    "‏";
})();

Porque aqui, a antecipação acionada por parênteses não é interrompida em nenhum
versão.

A correção ideal seria aplicar diretivas durante a antecipação. Infelizmente, devido
à natureza altamente flexível das diretivas em linha do JSHint, isso não é
possível. Os usuários esperam que as diretivas tenham "escopo de função", o que significa que o lexer
precisaria estar ciente da semântica circundante dos tokens que produz.

Enviei uma correção aqui: gh-3016. A longo prazo, penso que devemos considerar
outras melhorias na heurística de antecipação - sem o ponto e vírgula (inválido)
verificação, a prática comum de agrupar programas inteiros em um IIFE causará
JSHint para inicialmente lex todas as entradas.

Obrigado pela explicação detalhada!
Eu vejo como isso pode ser complicado sem adicionar uma imensa quantidade de trabalho extra para escopos.
Vamos nos ater ao 2.9.2 por um tempo, pois ele funciona para nossos arquivos e analisaremos a divisão das partes problemáticas em blocos que podemos gerenciar no futuro :)

A correção para este bug já está disponível na versão 2.9.4 do JSHint recém-publicado:

http://jshint.com/blog/2016-10-20/release-2-9-4/

Por favor, deixe-nos saber se você ainda está tendo problemas com essa versão!