Опыт разработки плагина для IntelliJ IDEA
TL; DR: Статья раскрывает опыт создания плагина для IntelliJ IDEA без глубокого погружения в технические подробности. Описан полный цикл разработки — от мотивации и идеи до публикации плагина.
Привет! В этой статье я хочу поделиться своим опытом создания плагина для среды разработки от JetBrains — Infrastructure as Code Security Linter. Плагин позволяет находить проблемы в Dockerfile и docker-compose файлах, как Hadolint, только делает это на лету и интегрирован в IDE.
Мотивация
Буду предельно честен: линтеров для Docker-файлов предостаточно. Схожие решения можно найти в маркетплейсе плагинов. В свою очередь, я хотел сделать удобный инструмент, который будет отлично интегрирован в IDE без установки внешнего софта, а также создать свой первый open-source проект.
Я был очарован тем, как плагины находят и выявляют проблемы. Я хотел понять, что за этим стоит, создать что-то крутое самому, помочь другим разработчикам быстрее находить проблемы и улучшить качество своих проектов.
Всегда, когда пользовался IntelliJ IDEA, я был увлечён тем, как встроенные проверки и сторонние плагины находят проблемы. Я хотел понять, как сделать что-то схожее самостоятельно. Я хотел разобраться, что за этим стоит, создать что-то крутое самому, помочь другим разработчикам быстрее находить проблемы и улучшить качество своих проектов.
Ну и, конечно же, работа над линтером — это не только написание кода. Ты должен постоянно изучать новые статьи, исследования, читать форумы и планировать новые инспекции, а ещё проводить собственные исследования, тестировать и преодолевать кучу сложностей, с которыми сталкиваешься.
Процесс разработки
1. Настройка проекта
Самое первое и очевидное — это установка необходимой среды разработки для создания плагина. Выбор очевиден: я использовал IntelliJ IDEA в редакции Community.
После этого последовало изучение документации, и я нашёл отличный стартовый шаблон, с которого можно спокойно начинать разработку.
Вооружившись шаблоном, я создал git-репозиторий на GitHub и приступил к процессу разработки.
2. Идея: Анализ безопасности of Infrastructure As Code (IaC) файлов
Долгое время я хотел сделать свой инструмент для проверки Dockerfile и других IaC-файлов. Такой инструмент должен был поддерживать множество различных форматов и технологий, находить уязвимости и проблемы в конфигурации, а также давать советы по лучшим практикам.
Множество таких инструментов работают из консоли и требуют дополнительной настройки и интеграции. В свою очередь, я планировал разработать плагин, который будет работать «из коробки» и максимально использовать встроенные функции среды разработки.
3. Поиск правил для проверки
Мир open-source программ огромный, и я приступил к анализу существующих утилит. Две из тех, что я нашёл, были Trivy и Hadolint. Эти два инструмента имеют прекрасный набор правил для проверки Docker-файлов.
Для Trivy даже есть плагин для среды разработки, но он работает через запуск бинаря в системе и просто отображает отчёт в среде разработки. У меня, например, с некоторой периодичностью он выдаёт различные ошибки. Для Hadolint нет плагина к среде разработки, и, пользуясь этим, я немного порекламировал своё решение в соответствующей issue.
Я решил сперва воспроизвести все проверки, которые предоставляет Trivy — их вышло около 20 штук. Я углублялся в проблематику каждой проверки: почему это важно, как это правильно реализовать и какие есть пограничные случаи, которые нужно покрыть. Благодаря этому я научился глубоко понимать специфику Docker-файлов.
4. Работа с плагином Docker и PSI
Для лучшей интеграции моих инспекций в IDE мне понадобилась зависимость от плагина Docker, который разработан компанией JetBrains. Плагин предоставляет поддержку подсветки синтаксиса и возможности по парсингу Dockerfile.
При разработке инспекций платформа IntelliJ предоставляет PSI (Program Structure Interface) — отличное решение, которое позволяет работать с логической структурой файла. Например, PSI позволяет найти необходимые элементы, проанализировать их, чтобы впоследствии подсветить потенциальные проблемы. С момента, как я реализовал свои первые инспекции, я понял, насколько это сильная технология. PSI позволяет обрабатывать как весь файл, так и отдельные его элементы в зависимости от потребностей.
5. Дальнейшая разработка
Имплементировав все правила из Trivy по работе с Docker-файлами, я спросил себя: что дальше? Конечно же, создать больше правил.
Я переключился на правила, поставляемые с Hadolint, и приступил к работе над расширением набора правил. Я спланировал работу над инспекциями и организовал небольшой task-менеджмент в GitHub issues.
Я нацелился на то, чтобы мой набор правил получился более обширным, чем у Hadolint, но, забегая вперёд, — этой цели я пока не достиг. Создать план по разработке правил — дело лёгкое, сложнее его выполнить.
В ходе работы я столкнулся с бесчисленными вопросами и проблемами, которые требуют знаний платформы IntelliJ Platform и внутренней структуры Docker-плагина. Так или иначе, сложности, которые возникают в процессе, делают его более увлекательным.
6. Тестирование и борьба за стабильность
Один из важнейших уроков, что я вынес из разработки плагина, — обязательность написания unit-тестов. С самого начала я описал множество тест-кейсов, чтобы покрыть мои инспекции и убедиться, что всё работает должным образом. Это значительно ускорило разработку и частично защитило меня от технического долга.
В ходе работы я часто переписывал инспекции, чтобы они работали лучше или использовали какие-нибудь общие интерфейсы, ну и, конечно же, чтобы исправлять баги.
Но даже если у вас есть тесты, это ещё не стопроцентная гарантия, что всё будет работать как надо, особенно если речь о работе плагина в разных версиях среды разработки.
Например, проблемы совместимости в разных версиях IDE не всегда можно выявить только с помощью тестирования — либо этот процесс будет значительно усложнён. Изначально я адаптировал свой плагин для версий 233 (версия от 2023 года) и новее, но спустя несколько релизов и тестирования на последних версиях я понял, что некоторые инспекции не подсвечивают проблемы.
Новейшие версии среды разработки используют немного обновлённый подход к обходу PSI-элементов, что создало проблемы с работой инспекций, так как мой подход был основан на последовательном обходе PSI-дерева. Из-за этого мне пришлось значительно переработать некоторые инспекции, так как они тестировали полностью файл, а не отдельные его элементы.
Выводы и дальнейшие шаги
Разработка плагина оказалась более увлекательной и сложной, чем я изначально предполагал, но это позволило мне постоянно работать, подогревая интерес к этому.
О знаниях
Разработка плагинов и инспекций — отличный способ исследования возможностей IDE и улучшения экспертизы в определённой технологии. Для меня это был Docker.
Понимание того, почему что-то является проблемой и как это приводит к ошибкам и уязвимостям, помогло мне начать смотреть на вещи под другим углом.
Но наибольший инсайт, который я получил, — это то, что разработка плагинов оттачивает ваши навыки программирования и расширяет понимание внутренней структуры используемой среды разработки. Знание того, что находится «под капотом» вашей среды разработки или плагина, даёт доступ к «тёмным знаниям» — чему-то невидимому большинству разработчиков.
Создание чего-то с нуля и публикация в маркетплейсе даёт неоценимый опыт, который сложно получить в рутине будней обычного разработчика.
Пользовательские результаты
С октября 2024 года плагин был загружен более 1600 раз, что особенно ценно для меня, учитывая, что это происходило почти без какого-либо продвижения.
Я упомянул свой плагин в issue на GitHub, сделал пару постов на Reddit, что дало мне некоторую обратную связь, и поделился ссылкой на плагин с коллегами.
Несмотря на минимальное продвижение, количество загрузок потихоньку растёт, и я очень ценю каждого пользователя, который установил моё решение и дал плагину шанс.
Что дальше
Спустя более чем 10 релизов и бесчисленное количество исправлений и улучшений я достиг одной из своих целей — я создал плагин, который помогает находить различные проблемы в Docker-файлах. Я также приложил достаточно времени, чтобы описать документацию, в которой указаны доступные проверки и способы решения проблем.
Я планирую продолжать работу над проектом, понемногу добавляя инспекции и исправляя проблемы, но темпы разработки однозначно снижу. Сейчас я хочу сместить фокус на другую часть разработки продукта —, а именно на продвижение плагина и создание небольшого комьюнити.
Я хотел бы, чтобы больше разработчиков опробовали плагин, использовали его в своей работе, делились обратной связью и, может быть, даже что-то в него контрибьютили.
Сообщество, по моему мнению, очень важно для open-source продуктов. Сначала ты один создаёшь продукт, но чтобы сделать его более ценным, нужны люди, которые будут поддерживать рост продукта: использовать его, давать обратную связь. Я хотел сделать инструмент, которым разработчики будут пользоваться в своих задачах.
Если вы хотите поддержать проект, вы можете поставить звёздочку на репозиторий, опробовать плагин в действии и, что самое важное, — поделиться фидбэком.
Если статья понравится, обязательно в следующей части поделюсь более глубокими техническими подробностями, болью, страданиями и радостью от процесса разработки.
