Комментарии 9
Но нужно заметить, что этот language server, скажем так, немного экспериментальный :). По-хорошему для language server лучше было бы использовать толерантный парсер (типа такого: https://github.com/emilioastarita/gphp), поскольку иначе очень сложно давать подсказки по неполному коду. Но в проекте уже используется полноценный парсер, так что по сути в language server режиме используется очень много костылей, чтобы заставить базовые вещи работать (а более сложные случаи не работают). Тем не менее, я лично пользовался language server режимом в VK вместо PHPStorm, но иногда, конечно, возможностей шторма не хватало.
- он не умеет работать с nowdoc'ами (валит panic'и в консоль, github.com/VKCOM/noverify/issues/327)
- считает, что класс не имеет доступа до protected и private свойств и методов, подключённых в него через trait (https://github.com/VKCOM/noverify/issues/283)
- считает, что если в классе реализуется интерфейс, то все методы интерфейса должны быть определены, даже если класс абстрактный (https://github.com/VKCOM/noverify/issues/326)
И много чего ещё, если заглянуть к ним в issues на github'е.
В целом, всё это замечательно, но напоминает внутренний продукт VK для VK. Для использования в новом проекте, реализуемом на php 7.4 или 7.3 (не уверен, что кто-то горит желанием начинать на 7.2, который кончится в ноябре, а про остальных олдфагов мы и вовсе умолчим), он явно не подходит. А глядя на активность в issues проекта, можно понять, что занимаются им по остаточному принципу и рассказали о нём всему миру больше для привлечения внимания к VK, чем для пользы разработчикам.
В целом, PR во время чумы.
Как минимум интересной может быть особенность линтера в плане расширяемости.
Не так много статических анализаторов позволяют описывать правила в виде синтаксических шаблонов. См. Как добавить проверки в NoVerify, не написав ни строчки Go-кода.
Так что я думаю польза для разработчиков может быть хотя бы из того, что можно подсмотреть в код и позаимствовать некоторые идеи.
Я постарался собрать список других проектов, которые так или иначе используют шаблоны для статического анализа. Можно туда так же добавить расширения ES Lint и подобные, но всё-таки там не AST-шаблоны, а своеобразный DSL из ключей-значений.
Также несколько раз делались разборы Open-Source проектов через NoVerify, после чего меинтейнерам отправлялись патчи с исправлениями багов. Тоже некоторая польза сообществу. :)
В целом, всё это замечательно, но напоминает внутренний продукт VK для VK.
(Если что, я изначальный автор noverify, но больше в VK не работаю, так что это моё субъективное мнение)
Не поймите неправильно, noverify действительно разрабатывался прежде всего для нужд VK и это не секрет, что legacy-часть кодовой базы VK весьма специфична и сделана практически без ООП, и существующие линтеры на PHP, к сожалению, не получилось бы использовать (по крайней мере чтобы они работали более-менее быстро) из-за необходимости держать в памяти все функции, глобальные переменные, и т.д., и загружать эти данные можно только в один поток тоже из-за особенностей самого PHP.
При этом, по крайней мере на тот момент, в VK также активно использовался и обычный PHP, но в первую очередь, конечно же, в линтер добавлялась поддержка того, что используется в кодовой базе VK (и PHP-библиотеках, которые VK использует). Изначально задачи поддержать всё, особенно самые последние новшества PHP, не было.
Но я не согласен с Вашим выводом. С момента выпуска noverify в open-source было закрыто больше issues, чем сейчас открыто (90 штук на момент написания поста: https://github.com/VKCOM/noverify/issues?q=is%3Aissue+is%3Aclosed). Большинство из этих issues созданы самим же Искандером quasilyte. Если бы проект действительно не развивался и баги не исправлялись (или вообще в трекере было 0 issues), тогда действительно стоило бы начинать беспокоиться. Некоторые баги, безусловно, сложнее исправить, чем другие, например вышеупомянутый баг с nowdoc это ошибка используемого парсера, а не noverify. В целом, конечно, тот факт, что проект на Go, усложняет возможность законтрибутить в проект, однако это не помешало тем 18 людям, которые числятся в списке contributors на гитхабе проекта.
То есть, конечно же, использовать noverify для совсем новых проектов с использованием всех последних фич PHP 7.4 — не лучшая идея. Но вам это и не нужно! Noverify хорошо себя показывает по сравнению с остальными линтерами на больших проектах, с кучей legacy, и там как раз польза от линтера будет намного больше, чем когда вы начинаете новый проект, следуя распоследним гайдлайнам и разрабатывая всё в PHPStorm или чем-нибудь таком.
Я — в целом нет, ибо я не работаю больше в ВК. Но линтер развивается Искандером quasilyte и Махневым Петром, и, кажется, развивается быстрее, чем когда только я за него отвечал.
NoVerify: PHP-линтер, который работает быстро