Проверка корректности кода с PHPLint. Валидация и корректировка стиля кода с CodeSniffer. Подключение статических анализаторов.
- 00:00:37 Проверка ошибок в PHP-файлах
- 00:02:32 PHP в режиме линтера
- 00:03:15 Массовая проверка файлов
- 00:04:25 Ускорение проверки
- 00:04:54 Использование PHPLint
- 00:08:40 Унификация Code Style
- 00:11:20 Подключение PHP-CodeSniffer
- 00:15:20 Синтаксические анализаторы кода
- 00:17:00 Обзор PHPStan, Psalm, Phan
- 00:17:59 Установка Psalm
- 00:21:04 Разбор ошибок
- 00:24:47 Добавление типов
- 00:27:32 Какой анализатор выбрать
- 00:29:30 Обзор результата
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо :)
команда make init не заработала, ошибка: Generating autoload files ocramius/package-versions: Generating version class... ocramius/package-versions: ...done generating version class docker run --rm -v /api:/app -w /app alpine chmod 777 var chmod: var: No such file or directory Makefile:26: recipe for target 'api-permissions' failed make: *** [api-permissions] Error 1
На Линукс Ubuntu 18.04 всё ок, видимо, какие то не поладки в видовс, с вагрантом...
Еще однин мученик на винде :) Скажите как вы организовали свою работу, особенно где у вас установлен PhpStorm? как прокинули портя в Винду?
Никаких мучений не испытываю. C Виндовс 10 про (там PhpStorm): Vagrant UP...-> VM (Ubuntu 16 голый - там инсталируем docker-compose и др.) -> вид 192.168.56.101:8081, 192.168.56.101:8080. В PhpStorme VM достигаем через ssh (C:\Users\arsku\projects\lPggCH\puphpet\files\dot\ssh\id_rsa)... и т.д.
я так понимаю докер вы не используете, поэтому и мучений нет :)
Docker у меня не в Винде, а в VM (которую запускаю с Vagrant), Vagrant позволяет работать с тем-же каталогами и от Виндовса (там PhpStorm и вид в Crome через 192.168.56.101) и от Линукса (там же Docker и др). Дайте емайл - скину скрин-шот (извините за ошибки...)
Vagrant and VirtualBox моя рабочая среда :) , в смысле для работы. tvjelgava@gmail.com И Vgrantfile скиньте, хочу посмотреть какие порты пробрасываете.
Сильно тормозит такой набор?
Пока не тормозит. с Vagrantfile не заморачиваюсь. Скинул.
Интересно, как Вы без Виндовс задействуете работу с кассовими апаратами и др. бизнес приборими (им надо ActiveX), ведь в магазинах, офисах стоит ВИНДОВС :)
Я вас цельком поддерживаю MS Word никто не отменял. Просто я давно присматриваеюсь к Докеру и не видел в нем особой пользы, но сейчас всё проясняется и мне бы хотелось его использовать. Думал вы тоже с этим бьётесь и можно было обменятся опытом.
после make up, команды: make lint и make analyze прошли успешно.
У меня у одного видео при просмотре подвисает?
У меня всё нормально воспроизводится. Может, у вас скорость интернет-соединения низкая?
Сейчас все хорошо даже на 2х скорости. Но вчера вечером даже на нормальной скорости были подвисания.
Что вы думаете по поводу анализатора phan ? от творца php, пишут что он единственный настоящий статический анализатор - так как строит синтаксическое дерево при анализе. Но он сложноват в настройке.
У меня под Виндой линтер ругается : End of line character is invalid; expected "\n" but found "\r\n"
Если делать деплой git-ом, то это заменятся автоматически, должен ли я это сообщение добавить в игнор, или всё таки нужно фиксить?
Настройте в редакторе использование "\n" для файлов.
Дмитрий, позвольте получить от вас комментарий, что за phpspec, что за зверь такой, почему мы его не используем и чем он отличается от mockery? Спасибо.
Mockery - это независимая библиотека для создания моков и стабов вместо createMock и createStab.
PHPSpec как Behavior Driven тестовый фреймворк позволяет записывать юнит-тесты через описание поведения кода более человекочитаемым языком.
BDD подход мы будем использовать для написания приёмочных тестов.
Дмитрий, у меня после добавления "squizlabs/php_codesniffer" или "overtrue/phplint" в composer.json и запуска make api-composer-install не происходит установки этих библиотек через Composer.
Composer выводит сообщение:
При запуске composer install и при наличии файла composer.lock не проверяются изменения в файле composer.json. Приходится запускать вручную composer update.
Что вы можете посоветовать в данном случае?
Да, в lock-файле сохраняется хэш зависимостей из файла composer.json. И при ручном изменении это ломается. Так что добавляйте зависимости в файл не вручную, а через require:
Иначе если правите вручную, то придётся запускать
composer update
, чтобы хэш персчитался. Но это обновит все пакеты.Добрый день, Дмитрий! Спасибо за отличное руководство!
Недавно стал использовать Убунту для разработки и постоянно сталкиваюсь с ошибками которых не было на Виндовс. Самые частые из них - ошибки доступа к файлам. Приходится переназначать владельца, группу, права. И в связи с этим вопрос:
api-permissions:
Многие пишут, что выдавать 777 не очень хорошо.
Для api использовал Laravel, там есть директория storage. Для неё пришлось продублировать chmod 777 с флагом -R. Иначе не работало.
Это нормально или есть другие варианты?
Для локальной разработки ставить 777 нормально, так как php-fpm и php-cli работают от разных пользователей и иначе не смогут записывать в общую примонтированную через
volumes
папку cvar
.А в продакшеновских Dockerfile уже можно ставить конкретные
chown
иchmod
для пользователяwww-data
вphp-fpm
и при желании дляapp
вphp-cli
, если там создаём пользователя вродеapp
как в будущем 59-ом эпизоде.Добрый вечер, Дмитрий.
Запустил проверку проекта psalm-ом.
Возникла проблема, не пойму как решить.
Проект на Symfony, по Вашему примеру https://github.com/ElisDN/demo-project-manager
Psalm выдаёт ошибки для src/Security/UserProvider и src/Security/UserChecker
Посмотрел в документации, там есть такая рекомендация.
https://psalm.dev/docs/running_psalm/issues/ParamNameMismatch/#config-allownamedargumentcallsfalse
В конфигурации psalm пробовал добавлять данные параметры - не помогло.
Как победить эти ошибки
Прочитать текст ошибки:
и переименовать параметр так, как он назван в методе интерфейса.
Это понятно, как самый простой вариант.
Но можно ли как-то решить по-другому?
Просто переименовать
$identity
в$user
, чтобы стало правильно.Зачем делать по-другому?
В данном случае интересно, почему рекомендации из документации не сработали?
В чём может быть причина?
Вы же не зря в примере переименовывали параметр? Как я понимаю для удобства чтения кода и понимания, что именно находится в переменной.
Может из-за приписки о классе A.
Назвал для однообразия, чтобы всё у меня называлось
identity
.А сейчас скорее назову
$user
по имени UserInterface, чтобы было технически корректно.Значит при использовании Psalm лучше избегать именования ради однообразия?
Значит, что при наследовании классов и реализации интерфейсов надо всегда придерживаться оригинальных сигнатур методов, чтобы не было неожиданностей в будущем. А Psalm лишь помогает сразу находить такие несовпадения.
Я уже это понял.
Но, поставил "чистый" Symfony ради эксперимента. Запустил Psalm - те же ошибки)))
В проекте поставил уровень ошибок psalm 4.
Для fetcher-ов получаю такую ошибку.
В самих fetcher-ах в select() передаю несколько аргументов, на это и ругается.
Если передать эти аргументы массивом, то psalm доволен.
Но в самом QueryBuilder для select() в комментарии предупреждение
Поискал в документации к psalm как можно решить данную проблему, но пока не нашёл.
Как можно отключить реагирование psalm на такие "ошибки"?
Можно подавить эту ошибку
TooManyArguments
конкретно для этого методаselect
.Благодарю.
В общем конфигурационном файле я подавил ошибку, но подумал, что если где-то я передам действительно большее число аргументов, то это будет плохо, поэтому интересовался как точечно подавить ошибку. Буду разбираться с этим.
Ещё вот такая ошибка возникает, никак не пойму, что именно psalm не нравится.
Ошибка возникает в файлах fixtures.
Вот пример
В этом случае тоже можно подавить ошибку, или можно как-то дать понять psalm, что именно в docblock описано?
Там как раз указано, как подавить только для одного метода через referencedMethod.
Ставьте тип перед переменной, а не после:
Да, я уже понял и поменял местами тип.
Как раз так и сделал.
Благодарю ещё раз.
Создается такое ощущение, что, например, тот же psalm обнаружит все баги, которые проверяет линтер. Есть пример, когда псалм ошибку не обнаружит, а линтер ругнется?
Да, Psalm тоже ругнётся, если в файле будет ошибка синтаксиса.
Просто удобно то, что быстрый PHPLint находит ошибки за несколько секунд. А Psalm приходится ждать целые минуты. Но если это не критично, то отдельный линтер можно не устанавливать.
Чем больше я узнаю, тем больше понимаю, что я ничего не знаю. Большое спасибо за уроки.
Как починить при втором композере?
Problem 1
Problem 2
Сделал вот так:
"require-dev": {
"vimeo/psalm": "^4.22"
и composer install помогли в итоге
Всем - доброго времени! Дмитрий и Юля - персонально! ) Не получается разобраться с ошибкой
Nothing to install or update Package jeremeamia/superclosure is abandoned, you should avoid using it. Use opis/closure instead. Package webmozart/path-util is abandoned, you should avoid using it. Use symfony/filesystem instead. Generating autoload files composer/package-versions-deprecated: Generating version class... composer/package-versions-deprecated: ...done generating version class 13 packages you are using are looking for funding. Use the
composer fund
command to find out more! docker run --rm -v /api:/app -w /app alpine chmod 777 var chmod: var: No such file or directory make: *** [Makefile:26: api-permissions] Ошибка 1В Makefile за комментировала api-permissions прошла вперед (на 10-12 роликов) в надежде что как-то ошибка сама-собой ) "отпадет" - нет, не получилось. Начала все сначала, хотела закрыть гештальт, еще раз дошла до этого момента, но увы, чуда не случилось, опять те же "грабли". Что посоветуете?
Работаю в Ubuntu 20.04
Или войти через: