Публикация расширения Firefox: где застряёт ревью в каталоге
Пакет собран, подписан и отправлен на проверку — а через несколько дней возвращается одной строкой «не соответствует политике». Что именно нарушено, из формулировки непонятно: то ли автоматика зацепилась за минифицированный код, то ли проверяющий не увидел обоснования для расширенных разрешений. Релизный цикл встаёт: сборка готова, но опубликовать её нельзя, а сроки проверки в каталоге заранее не объявляются и зависят от очереди и типа изменений.
Причины возврата пакета почти всегда технические и предсказуемые. Динамическое исполнение кода, подключение внешних скриптов, обфускация без приложенных исходников и инструкции по воспроизводимой сборке — это готовый повод для отказа. Отдельно ловят расхождение между заявленными разрешениями и реальным поведением: если дополнение запрашивает доступ к вкладкам, но в описании об этом нет ни слова, модерация дополнения вернёт пакет на доработку.
Само ревью идёт в два слоя: автоматические проверки на опасные вызовы и ручной разбор для тех сборок, где нужно оценить смысл поведения. Любое изменение в разрешениях или добавление внешних обращений переводит обновление в расширенную проверку, поэтому точечная правка стоит столько же времени, сколько крупный релиз. Повторная отправка без устранения первопричины приводит к тому же результату и сдвигает очередь.
Разбираем, как это закрывается: собираем пакет под требования каталога, готовим исходники и пояснения для проверяющих и ведём переписку до публикации — чтобы цикл не уходил на второй и третий круг.
Эффект от налаженного релиза: сроки, отказы, воспроизводимость
Первый измеримый эффект — предсказуемый срок прохождения проверки. Когда пакет собирается по одному регламенту (манифест, обоснование каждого разрешения, отсутствие удалённо подгружаемого кода, декларация обработки данных), ревью перестаёт возвращаться на формальности. Цикл проверки в каталоге Mozilla становится плановым: одна отправка вместо серии итераций «правка — ожидание — правка».
Второй эффект — падение доли отказов. Возврат на доработку обычно вызывает не логика кода, а расширение разрешений при обновлении, сжатый код без приложенных исходников и данные, собираемые без объявленной цели. Правило «новое разрешение добавляется только под конкретную функцию, с пояснением в описании» убирает этот класс отказов почти полностью — остаются единичные случаи.
Третий эффект — воспроизводимая сборка. Зафиксированные версии зависимостей, один сборщик и детерминированный порядок файлов в архиве дают одинаковый результат у любого инженера команды. Хэш собранного пакета совпадает с тем, что ушёл в каталог, поэтому откат на предыдущий подписанный выпуск занимает минуты, а не пересборку по памяти.
Четвёртый — прозрачный релиз. Журнал изменений пишется на языке пользователя, стабильный и тестовый каналы разведены, каждое обновление подтверждено подписью. Команда видит, что именно получили пользователи, а поддержка — с какой версии пришло обращение.
Способы поставки в каталог: ручная, автоматическая, отдельный канал
Расширение попадает к пользователям несколькими путями, и выбор между ними определяет, кто отвечает за обновления и проверку кода. Основной маршрут — каталог Firefox Add-ons: он раздаёт обновления автоматически и проверяет сборку перед выдачей, но каждую версию нужно собрать, подписать и провести через ревью.
Способ доставки выбирают по частоте релизов и по тому, насколько жёстко нужен ручной контроль на каждом шаге. Ниже — четыре рабочих варианта и их ограничения.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Ручная отправка пакета | редкие релизы, один-два в квартал; нужен контроль на каждом шаге | версия зависит от человека, шаги сборки и загрузки легко пропустить |
| Автоматическая сборка и отправка | регулярные релизы, воспроизводимая сборка, есть автотесты | ключи доступа хранятся в защищённом виде; при падении проверок релиз блокируется целиком |
| Самостоятельный канал обновлений | распространение внутри компании или вместе с другим продуктом | хостинг обновлений, подпись и совместимость остаются на вас, установка идёт вне каталога |
| Временная загрузка для тестов | проверка сборки до публикации, отладка на живом профиле | живёт до перезапуска браузера, не подписана, пользователям недоступна |
На практике варианты комбинируют: на этапе разработки удобна временная загрузка, для релиза — автоматическая отправка в каталог, а самостоятельный канал оставляют для закрытых контуров, где установка из каталога невозможна.
Этапы подготовки расширения: от аудита до передачи
Пакет расширения ревьюеры каталога разбирают по частям: распаковывают архив, сверяют сжатый код с исходниками и проверяют, зачем запрошены каждое разрешение и каждый домен. Поэтому «просто загрузить архив» превращается в цикл правок и повторных отправок, который тянет сроки релиза. Мы ведём подготовку как проект с фиксированными этапами — на выходе пакет, который проходит проверку с первого-второго захода.
- Аудит пакета. Разбираем текущую сборку: какие разрешения реально используются, есть ли удалённо подгружаемый код, остались ли сжатые участки, как собирается итоговый архив.
- Приведение манифеста к требованиям каталога. Сужаем разрешения до фактически нужных, убираем динамическую подгрузку скриптов, приводим описание, иконки и заявление об обработке данных к формату карточки.
- Схема каналов обновления. Определяем, какие сборки идут в публичный канал, какие — в закрытый тестовый, и как соотносятся номера версий, чтобы переход пользователя с тестовой ветки на релизную проходил без откатов.
- Подготовка исходников для проверки. Собираем читаемую версию кода и инструкцию по воспроизведению сборки — ревьюер должен получить ровно тот архив, который описан в инструкции.
- Отправка на ревью и сопровождение. Регистрируем черновик, отвечаем на замечания, вносим правки точечно, без полной пересборки и потери истории версий.
- Автоматизация выпуска и передача. Сборка, подпись и загрузка новой версии идут одним сценарием, поэтому содержимое архива и номер версии не расходятся. Отдаём схему каналов и порядок ответа на замечания — команда выпускает обновления сама.
Комплект на выходе: настройки, политики, документация
Комплект на выходе — не архив с исходниками, а рабочая система: по ней выпуск обновления делает инженер, который не участвовал в разработке. Каждый документ отвечает на один вопрос — зачем расширению это разрешение, как собрать валидный архив, что проверить до отправки на ревью.
- Политика разрешений. Таблица «разрешение — функция — участок кода»: каждое обосновано, неиспользуемые вырезаны. Большинство возвратов с ревью в AMO — про расхождение заявленных прав и реального поведения, поэтому список прав и описание в листинге сверяются построчно.
- Регламент выпуска обновлений. Пошаговый порядок: поднять версию, собрать архив, прогнать валидацию, отправить, дождаться проверки, зафиксировать результат. Отдельно отмечено, какие типы изменений проходят автопроверку, а какие уходят на ручное ревью.
- Документация по сборке. Команды сборки, состав исключаемых файлов, где лежат исходники и как приложить их, если архив минифицирован или собран транспиляцией.
- Чек-лист перед отправкой. Версия и номер сборки не расходятся, манифест ссылается только на существующие файлы, разрешения совпадают с политикой, описание и скриншоты актуальны, политика конфиденциальности опубликована.
- Шаблон листинга. Краткое и полное описание, категория, ключевые слова — заготовка, которую остаётся только обновить под новый функционал.
- Порядок отката. Что делать при дефекте после публикации: как снять проблемную версию, выпустить исправление и уведомить пользователей через описание обновления.
Документы лежат в репозитории рядом с кодом, а не в переписке, поэтому живут ровно столько, сколько живёт расширение. Передаём их вместе с доступами к аккаунту разработчика — дальнейшие публикации команда заказчика проводит самостоятельно.
Кейс: сократили цикл проверки и убрали повторные возвраты
Что было на входе
Расширение собиралось в один минифицированный файл, а манифест запрашивал доступ ко всем вкладкам и внешним хостам «на всякий случай». Проверка Firefox Add-ons в такой конфигурации не может убедиться, что код делает только заявленное, поэтому каждая отправка возвращалась с новым списком замечаний. Итераций доходило до четырёх — сначала права, затем исходники, затем расхождение карточки с реальным поведением; срок выхода обновления растягивался до трёх недель.
Что изменили
Пересобрали манифест: оставили минимальные права по хостам, часть логики перевели с постоянных разрешений на запрос в момент действия пользователя. Сборку сделали воспроизводимой — зависимости зафиксированы, шаги описаны, архив исходников совпадает с собранным пакетом. Прогнали линтер и проверку на запрещённые приёмы (исполнение внешнего кода, обфускация) до отправки, а описание в карточке привели к фактическому сбору данных.
| Показатель | До | После |
|---|---|---|
| Итераций проверки на релиз | 3-4 | 1 |
| Доля отправок с возвратом | около 60% | меньше 10% |
| Срок выхода обновления | до 3 недель | 4-5 дней |
Теперь обновление проходит с первого прохода: проверяющий подтверждает заявленные права и видит совпадение исходников со сборкой. Повторные возвраты почти исчезли, а дата релиза перестала быть непредсказуемой — планирование вех снова опирается на календарь, а не на переписку с проверкой.
Что делать, если пакет уже отклонён модератором?
Отклонение пакета — не приговор, а список конкретных замечаний: модератор указывает, какие пункты политики каталога нарушены и что именно нужно поправить. Чаще всего это запрошенные разрешения, не совпадающие с реальной функциональностью, код, подгружаемый извне, или нераскрытая обработка пользовательских данных. Первый шаг — прочитать письмо целиком и выписать замечания по пунктам, не пытаясь угадать мотив проверяющего.
Дальше — разбор замечаний с проверкой по коду. Мы воспроизводим сборку из исходников, сверяем манифест с фактически используемыми интерфейсами и убираем разрешения, без которых расширение работает: именно расхождение «просим больше, чем нужно» отклоняет большинство пакетов. Отдельно проходим по внешним подключениям и удалённо исполняемому коду — каталог требует, чтобы вся логика лежала внутри пакета и была обозрима проверяющему.
Правки делаем точечно: минимальный набор изменений, без попутного переписывания соседних модулей, чтобы повторная проверка не открывала новых вопросов. Версию в манифесте поднимаем и готовим короткое пояснение к отправке — по строке на каждое замечание, с указанием файла и сути правки. Так проверяющему не нужно сопоставлять старую и новую сборку вслепую.
Повторная отправка идёт тем же каналом, обычным обновлением, вместе с этим пояснением. Если замечание спорное или сформулировано неоднозначно, полезнее не отправлять пакет заново, а ответить в той же переписке: спокойно, по пунктам, со ссылкой на документацию платформы и просьбой уточнить, какой именно пункт политики применён к конкретному месту в коде. Повторная отправка идентичной сборки без ответа удлиняет проверку и повышает шанс, что следующий разбор будет строже.
Обращение к модератору — рабочий инструмент, а не конфликт. Формулируйте вопрос узко и по делу, фиксируйте ответы в документации проекта: тогда на следующем обновлении те же замечания не повторятся.
Технические сомнения: разрешения, манифест, обновления
Сомнения перед стартом обычно касаются трёх вещей: не отпугнёт ли пользователя список запрашиваемых прав, не сломает ли обновление уже установленные копии и что именно проверяет ревью. Ниже — как мы закрываем каждый из этих вопросов в проекте.
Можно ли обойтись минимальным набором разрешений?
Да, и это базовый принцип. Идём от сценария: если функция работает через активную вкладку и явно перечисленные хосты, запрос доступа ко всем сайтам не нужен. В описании к каждому праву даём ревьюеру обоснование — зачем это пользователю, а не «так собралось».
Что делать, если расширение собрано на старой ветке манифеста?
Переводим на актуальную: фоновый скрипт становится сервис-воркером, а подгружаемые части переносим внутрь сборки. Если продукт к переходу не готов, оставляем текущую ветку и фиксируем срок, до которого миграцию нужно закрыть, чтобы публикация не встала.
Как обновления доходят до установленных копий?
Публикуем версию — браузер сам подтягивает её у пользователей, без их участия. Для проверок держим отдельный канал: сборка уходит закрытому списку тестировщиков, в общий поток — только после подтверждения. Откат делается повторной загрузкой предыдущей версии, номер сборки при этом всегда растёт.
Можно ли подгружать код с сервера?
Нет, и это ограничение закладываем в архитектуру сразу. Весь исполняемый код должен лежать внутри пакета — внешние скрипты и динамический разбор строк ревью отклоняет. Логику, зависящую от конфигурации, выносим в данные, которые расширение получает, а не исполняет.
Обсудим задачу: пришлём оценку и план релиза
Чтобы оценка задачи была предметной, а не «плюс-минус», к запросу достаточно приложить несколько артефактов. По ним видно объём правок в манифесте, состояние сборки и вероятность возврата с ревью — из этого складывается план релиза с этапами и точками контроля.
Что приложить к запросу:
- Ссылку на репозиторий или архив с исходниками и команду сборки, которая воспроизводится с нуля.
- Текущий манифест: запрашиваемые разрешения и обоснование каждого — в Firefox ревьюеры смотрят на минимально необходимый набор.
- Перечень сетевых запросов и внешних сервисов, с которыми общается расширение, и какие данные туда уходят.
- Черновик карточки в магазине: название, описание, снимки интерфейса, локализация — их проверяют вместе с кодом.
- Ссылку на политику конфиденциальности или её черновик, если собираются пользовательские данные.
- Данные аккаунта разработчика и роль, от имени которой идёт публикация: без подтверждённого владельца выкладку не запустить.
- Пожелания по автоматизации: ручная загрузка версии или сборка и отправка на проверку по метке репозитория.
Часть материалов готовим сами и показываем до старта работ — отсутствие пункта из списка не повод откладывать разговор. Опишите задачу как есть: вернёмся с оценкой задачи и планом релиза, где видны этапы, ответственные и точки, в которых нужно ваше решение.
