Jshint: Отключение предупреждения для W100 не работает в 2.9.3

Спасибо за отчет! Это действительно регресс.

Не то, чтобы это сильно помогло вам, но похоже, что в новом выпуске обнаружилась ранее существовавшая ошибка — в процессе сокращения ввода, которым вы поделились, я смог столкнуться с этой проблемой и в версии 2.9.2.

Мне нужно немного отойти, но я надеюсь, что патч будет готов сегодня вечером (EST).

Вот история:

При обнаружении символа открывающей скобки ( ( ) в выражении
положение, синтаксический анализатор JavaScript с поддержкой ES2015, такой как JSHint, должен определить
отмечает ли он начало оператора группировки или стрелочной функции.

JSHint делает это, токенизируя все последующие входные данные, пока не найдет
«соответствующий» символ закрывающей скобки ( ) ). В этот момент он может сделать
определение характера производства, о котором идет речь, - если оно соблюдается
токеном => это стрелочная функция; в противном случае это оператор группировки.

Пока он смотрит вперед, он не применяет встроенные директивы, с которыми сталкивается.
например -W100 . Тем не менее, лексер отвечает за выброс определенного линтинга.
ошибки _включая_ W100 . Поэтому, как только JSHint начинает «заглядывать вперед», его
поведение в ответ на эти потенциально опасные символы «заблокировано».
(Это предлагает краткосрочное решение для всех, кто страдает от этой регрессии: отключить
W100 перед IIFE. Не идеально, я знаю, но учтите, что актуальность этогопредупреждение оспаривается .)

Эта регрессия произошла из-за, казалось бы, не связанного патча: gh-3003.
Раньше просмотр вперед отменялся, если был токен точки с запятой.
встречается, например:

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

...однако это оказалось недопустимой эвристикой, поскольку стрелочная функция
параметры могут сами содержать этот токен:

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

Поэтому мы удалили его, чтобы правильно распознавать стрелочные функции в таких случаях.

Имея это в виду, полностью сокращенный тестовый пример может быть немного более ясным (что
является непечатаемым символом \u200f в строковом литерале):

(function() {
    ;

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

До gh-3003 (например, JSHint в версии 2.9.2) точка с запятой останавливала
просмотр вперед, и непечатаемый символ не будет лексироваться до тех пор, пока _после_
Применена директива JSHint. С примененным исправлением JSHint лексизирует символ
_перед_ применением директивы и переходит к предупреждению.

Это также демонстрирует, что фундаментальная проблема существует даже в JSHint 2.9.2.
Следующий ввод неправильно вызывает предупреждение даже в этой версии
JSHint:

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

Потому что здесь просмотр вперед, запускаемый скобками, не прерывается ни в
версия.

Идеальным решением было бы применить директивы во время просмотра вперед. К сожалению, из-за
к очень гибкому характеру встроенных директив JSHint это не
возможный. Пользователи ожидают, что директивы имеют «область действия», то есть лексер.
должен был бы знать об окружающей семантике токенов, которые он производит.

Я отправил исправление здесь: gh-3016. В долгосрочной перспективе, я думаю, мы должны рассмотреть
другие улучшения эвристики просмотра вперед - без (недопустимой) точки с запятой
проверьте, обычная практика упаковки целых программ в IIFE вызовет
JSHint для первоначального лексирования всех входных данных.

Спасибо за подробное объяснение!
Я вижу, насколько сложным это может быть без добавления огромного количества дополнительной работы для областей видимости.
Мы какое-то время будем придерживаться версии 2.9.2, так как она работает с нашими файлами, и постараемся разбить проблемные части на блоки, которыми мы сможем управлять в будущем :)

Исправление этой ошибки теперь доступно в недавно опубликованной версии JSHint 2.9.4:

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

Пожалуйста, дайте нам знать, если у вас все еще есть проблемы с этой версией!