Manifest V3 сломал половину старых гайдов по Chrome-расширениям, и парсеры с инжекторами пострадали больше всего. Сервис-воркер засыпает через 30 секунд, webRequest подрезали до declarativeNetRequest, а ревью Web Store режет широкие permissions без разбора причин. Разберем, как собрать через вайбкодинг сложное расширение с парсером сайта, инжектором в контекст страницы и сервис-воркером, который не падает, а потом провести его через ревью Google без месяца ожидания.
Manifest V3 обязателен для всех Chrome-расширений с 2023 года, без него ничего не публикуется. Парсер строится на связке content script и declarativeNetRequest, инжектор работает через chrome.scripting с параметром world MAIN. Ниже готовый промпт для Cursor, реальные лимиты API и разбор, почему ревью Google чаще всего отклоняет именно сложные расширения.
документацией Chrome for Developers.
Почему Manifest V3 в 2026 году стал единственным вариантом для сложных расширений
Manifest V2 отключен полностью, Google принимает только Manifest V3. Это не косметическое обновление, а смена архитектуры: сервис-воркер вместо постоянного фона, декларативные правила вместо перехвата трафика в реальном времени.
Host permissions теперь отдельная, видимая пользователю поверхность. Google выстроила систему так, что каждое разрешение расширения можно аудировать и отозвать вручную из настроек браузера. declarativeNetRequest заменил открытый webRequest, а сервис-воркеры заменили постоянные background pages. Это архитектурный сдвиг в сторону приватности, а не просто новая цифра в версии манифеста.
Google перевела экосистему на Manifest V3 еще в 2023 году, и с тех пор Chrome Web Store не принимает новые расширения на старом формате. Для парсеров это ощутимая смена правил. Раньше webRequest давал доступ к телу каждого запроса и позволял на лету менять логику обработки. Сейчас declarativeNetRequest работает только по заранее описанным правилам, без произвольного JS внутри самого правила. Из плюсов, расширение больше не может незаметно читать чужой трафик, и это снижает подозрительность в глазах ревьюера. Из минусов, сложную условную логику парсинга приходится переносить в content script и сервис-воркер, а не в перехватчик сети.
Отдельная ловушка для вайбкодеров: Cursor и Claude Code часто тянут примеры background pages из Manifest V2 просто потому, что таких примеров больше в обучающих данных. Если явно не указать версию манифеста в промпте, модель сгенерирует нерабочий код. В шаблоне промпта ниже это учтено отдельным пунктом.
Как устроен background service worker и почему он ломает парсеры
Сервис-воркер не висит в памяти постоянно, он загружается на событие и выгружается через 30 секунд бездействия. Долгие сетевые запросы парсера, которые не укладываются в это окно, просто обрываются.
Таймер простоя сервис-воркера равен 30 секундам, и любое обращение к chrome API сбрасывает его заново. Если парсер делает долгий fetch без периодических вызовов chrome.* внутри, воркер выгрузится раньше, чем запрос завершится, и результат парсинга пропадет без единой ошибки в консоли.
Сервис-воркер, центральный обработчик событий расширения, прописан в manifest.json через ключ background.service_worker. Он не похож на классический background page: подключается только когда нужен, работает в отдельном потоке и не блокирует DOM. Жизненный цикл простой: установка, старт при запуске профиля, выгрузка при простое. Событие onInstalled идеально подходит для одноразовой инициализации, например записи ID пользователя в базу при первой установке. onStartup срабатывает, когда пользователь запускает Chrome с уже установленным расширением. Для парсера вывод один: логику опроса сайта нельзя завязывать на глобальные переменные внутри воркера, они обнуляются при каждой выгрузке.
Что делать с состоянием и долгими запросами парсера
Хранить промежуточные данные нужно через chrome.storage.local, а не через let или const на верхнем уровне файла. Если запрос к сайту занимает больше 30 секунд, разбивайте его на шаги и между ними дергайте любой chrome API, это сбрасывает таймер простоя. На практике проще держать воркер активным через chrome.alarms с интервалом в 20-25 секунд, пока идет длительная операция парсинга.
Как написать парсер сайта через content script без блокировки ревью
Парсер, который читает DOM конкретного сайта, обычно не требует host_permissions на весь интернет. activeTab плюс content script, ограниченный полем matches в manifest.json, закрывает большинство сценариев и проходит автопроверку быстрее.
declarativeNetRequest гарантирует до 30 000 статических правил на расширение, а лимиты на динамические и сессионные правила с Chrome 120 считаются отдельно друг от друга. Для парсера этого хватает с запасом, но правило не даст прочитать тело ответа, только заблокировать запрос, перенаправить его или изменить заголовки.
Связка для парсера обычно такая: content script матчится на конкретный домен через поле matches и читает DOM после загрузки страницы. Если нужно перехватывать конкретные сетевые запросы, например XHR к внутреннему API сайта, в дело идет declarativeNetRequest, он умеет блокировать, редиректить и менять заголовки декларативно, без доступа к содержимому ответа. Разработчики Chrome называют это компромиссом приватности в Manifest V3: расширение больше не видит сырой трафик, зато пользователь видит, что расширение не видит сырой трафик. Для сайтов с бесконечной прокруткой парсер логичнее строить на MutationObserver внутри content script, а не на периодическом опросе DOM: событие сработает сразу, как только сайт подгрузит новые элементы, и не будет лишних циклов в сервис-воркере.
| Тип правил declarativeNetRequest | Что известно точно |
|---|---|
| Гарантированные статические правила | 30 000 на расширение |
| Динамические плюс сессионные правила | лимиты разделены с Chrome 120, значения читаются из констант API в рантайме |
| Регулярные выражения в правилах | ограничены отдельной константой, проверяйте перед публикацией |
| Наборы статических правил (rulesets) | лимит задан константой MAX_NUMBER_OF_STATIC_RULESETS |
Чем инжектор в MAIN world отличается от обычного content script
Content script по умолчанию работает в ISOLATED world, видит DOM страницы, но не видит ее JS-переменные. Инжектору нужен доступ к window сайта, и для этого chrome.scripting.executeScript запускают с параметром world MAIN.
ISOLATED world это отдельное JS-окружение, которое видит тот же DOM, что и страница, но не делит с ней переменные и функции. Если инжектору нужно вызвать функцию из window объекта сайта или прочитать его внутренний state, единственный легальный путь в Manifest V3, это executeScript с world MAIN, без eval и без ручной вставки script-тегов.
Раньше для доступа к window страницы расширения вставляли script-тег через DOM, и это работало, но выглядело как обход политики безопасности. В Manifest V3 для этого есть штатный параметр world у chrome.scripting.executeScript: значение MAIN выполняет функцию прямо в контексте страницы, ISOLATED, в изолированном окружении расширения. Обмен данными между двумя мирами идет только через postMessage или CustomEvent, напрямую до объекта окна из content script в ISOLATED не дотянуться. Google отдельно предупреждает про раздел политики о remotely hosted code: любое выполнение произвольных строк как кода, будь то new Function или удаленный скрипт с внешнего сервера, прямое нарушение и повод для блокировки уже на этапе автоматической проверки.
Какой промпт использовать в Cursor для генерации парсера на Manifest V3
Промпт должен явно фиксировать версию манифеста, тип парсинга, границы permissions и формат вывода данных. Иначе модель добавит лишние host_permissions или откатится к паттернам Manifest V2 из обучающих данных.
Промпт-шаблон ниже собран под три сценария: DOM-парсер, сетевой инжектор и их комбинацию. Главное правило вайбкодинга расширений: фиксировать в первой строке промпта Manifest V3 и точный список permissions, иначе модель по умолчанию тянет устаревшие примеры.
Промпт для генерации DOM-парсера с сервис-воркером:
Собери Chrome-расширение на Manifest V3 (manifest_version: 3), НЕ Manifest V2.
Задача: парсить [конкретные данные] на сайте [домен].
Структура:
- content script с matches только на [домен], читает DOM через MutationObserver
- background service worker: принимает сообщения от content script через
chrome.runtime.onMessage, сохраняет данные в chrome.storage.local
- popup.html показывает последние N собранных записей
Permissions: только activeTab и storage.
Host_permissions не добавляй, если не нужен доступ вне activeTab.
После генерации объясни, какие permissions ты добавил и зачем каждый нужен,
мне нужно вписать это в форму ревью Chrome Web Store.Что делает: задает архитектуру из трех частей и явно ограничивает permissions. Когда использовать: любой парсер конкретного сайта без фоновой сетевой активности. Почему работает: явное указание manifest_version 3 и прямой запрет на паттерны V2 обрубает большинство типовых ошибок генерации. Лайфхак: последняя строка про форму ревью экономит потом час на заполнении permission justification вручную, модель сама пишет обоснование под каждый пункт, а вам остается только проверить формулировки.
Как пройти ревью Chrome Web Store с парсерами и инжекторами
Ревью Web Store работает в два трека: автоматический быстрый и ручной глубокий. Расширения с парсерами и инжекторами почти всегда попадают во второй, потому что используют scripting и host_permissions за пределами activeTab.
Простое расширение только с activeTab способно пройти автопроверку за считанные минуты. Расширения с широкими host_permissions или чувствительными API попадают на ручную проверку и ждут от нескольких дней до трех недель. Повторная отправка после отклонения не ускоряет очередь, она просто встает в конец.
Google описывает два трека проверки. Track 1, автоматическое сканирование на сигнатуры вредоносного кода и явные нарушения политики, для узких permissions занимает до часа. Track 2, ручная проверка живым человеком: он читает permission justification, сверяет заявленное с тем, что реально делает код, и смотрит скриншоты листинга. Парсер, который лезет в DOM конкретного сайта, и инжектор, который выполняет код в MAIN world, почти всегда получают Track 2, потому что используют scripting и, часто, host_permissions шире activeTab. Практика от разработчиков, которые постоянно публикуют в Web Store: заявку лучше подавать во вторник, среду или четверг, по пятницам очередь до понедельника почти не двигается. Версию в manifest.json нужно бампать при каждом обновлении кода и заполнять release notes, ревьюер сверяется именно с ними.
| Трек ревью | Что проверяет | Типичное время |
|---|---|---|
| Track 1, авто | Сигнатуры вредоносного кода, явные нарушения политики | От минут до часа |
| Track 2, ручной | Permission justification, соответствие кода описанию, скриншоты | От нескольких дней до трех недель |
Какие ошибки чаще всего заваливают ревью
Три причины отклонения повторяются чаще остальных: заявленные permissions не совпадают с вызовами в коде, host_permissions шире, чем нужно функциям расширения, и политика конфиденциальности недоступна по ссылке.
Автоматический анализ сверяет вызовы chrome API с декларацией в манифесте. Если код обращается к chrome.history, а permission не заявлен, или заявлен, но вкладка Privacy утверждает, что данные не собираются, это прямое противоречие и повод для отклонения без объяснений от живого человека.
Первая типичная ошибка, несовпадение задекларированных permissions с фактическими вызовами API, автоматика ловит это моментально. Вторая, host_permissions на все хосты через <all_urls>, когда парсер реально работает с одним доменом: ревьюер попросит сузить область или откажет сразу. Третья, страница политики конфиденциальности отдает 404 или требует логина, а ссылка на нее обязательна для любого расширения, которое трогает пользовательские данные. Четвертая, отдельная для инжекторов, попытка выполнить строку кода через eval или подтянуть скрипт с внешнего сервера. Это нарушение раздела про remotely hosted code, и здесь не спасет даже подробное объяснение в justification.
Какую AI-модель выбрать для генерации сложных расширений
Для рядового content script хватает Claude Sonnet 4.6, баланс цены и качества. На архитектуру с несколькими сервис-воркерами и инжекторами в разных world лучше переключаться на Opus 4.8, а DeepSeek V4 Pro Max ощутимо дешевле при сравнимом уровне на простых задачах.
Claude Sonnet 4.6 стоит 3 доллара за миллион входных токенов и 15 за миллион выходных, этого достаточно для большинства задач по генерации расширений. Для архитектуры с несколькими service worker и MAIN-world инжекцией разумнее взять Opus 4.8, разница в цене окупается меньшим числом итераций на исправление ошибок.
| Модель | Цена, вход/выход за 1M токенов | Когда брать для расширений |
|---|---|---|
| Claude Sonnet 4.6 | $3 / $15 | Стандартный парсер, один content script, повседневная работа в Cursor |
| Claude Opus 4.8 | $5 / $25 | Сложная архитектура: несколько service worker, инжекторы в MAIN world |
| DeepSeek V4 Pro Max | $0.435 / $0.87 | Черновая генерация типового boilerplate под несколько сайтов сразу |
На практике разница ощущается не в синтаксисе манифеста, его любая современная модель пишет без ошибок, а в понимании границы между ISOLATED и MAIN world. Opus 4.8 реже путает permissions и почти не тянет паттерны Manifest V2 из старых обучающих данных, но стоит дороже. Sonnet 4.6, разумный дефолт для большинства задач: content script плюс один сервис-воркер он собирает с первого раза. DeepSeek V4 Pro Max по цене почти бесплатный, и для потоковой генерации однотипных парсеров под разные сайты он оправдан, хотя логику permissions после генерации стоит перепроверить руками.
Плюсы и минусы вайбкодинга сложных расширений
Вайбкодинг закрывает архитектуру и типовые ошибки Manifest V3 за часы вместо недель. Слабое место, ревью и permission justification модель пишет по шаблону, и его все равно нужно перечитывать вручную перед отправкой.
Сильная сторона вайбкодинга здесь, скорость итерации. Cursor и Claude Code за минуты меняют логику парсера под новую верстку сайта, чего вручную не сделать так быстро. Слабая сторона, модель не видит реального решения ревьюера Google, и permission justification придется перепроверять человеку, который понимает, что реально делает код.
Сильные стороны:
- Архитектура из content script, сервис-воркера и popup генерируется за один заход, если промпт зафиксировал версию манифеста и границы permissions.
- Модель сама объясняет назначение каждого permission, это объяснение почти без правок можно вставить в форму ревью.
- Правки под изменение верстки сайта занимают минуты, а не часы поиска нужного селектора руками.
Слабые стороны:
- Модель не проходит реальное ревью Google за вас, justification нужно перечитывать самому перед отправкой.
- Widely-scoped permissions иногда добавляются по умолчанию, если промпт явно не ограничил их.
- Для инжекторов в MAIN world модель иногда предлагает решение через eval, а это сразу нарушает политику Web Store.
Максим: «Мог просто засесть до пяти ночи и править одну функцию, которая не работала. В моменте уже вспотел, хотелось все закрыть. Но понимал, что это решается, просто нужно докопаться до причины и идти дальше. С расширениями та же история: правишь world и permissions, пока не поймает и не заработает.»
Кому подходит связка вайбкодинг и сложные Chrome-расширения
Формат подходит вайбкодерам и маркетологам, которым нужен рабочий инструмент под конкретную задачу, а не расширение на миллион пользователей: скрапер данных, инжектор для автоматизации рутины, парсер цен конкурентов.
Claude Code за пару часов собирает связку краулер плюс парсер продукта, если задача, собрать данные с конкретного сайта под конкретную структуру: URL продуктов, цены, изображения. Для внутренних инструментов команды или личных микропродуктов ревью Web Store вообще не обязательно, расширение можно грузить как unpacked.
Формат ложится на принцип трех единичек: один сайт, одна задача, один формат вывода. Не обязательно сразу целиться в публикацию: для внутренних задач команды или личного проекта расширение можно держать в режиме unpacked и вообще не проходить ревью. Публикация в Web Store нужна, только если планируется дистрибуция за пределами своей команды. Каталог инструментов на vibecoderz.ru/ide держит актуальные обзоры и Cursor, и Claude Code с примерами промптов под разные задачи, если нужно сравнить, какой инструмент быстрее соберет конкретно вашу связку парсер плюс инжектор.
Частые вопросы про Manifest V3 и сложные расширения
Что такое Manifest V3 простыми словами? Это обязательный с 2023 года формат конфигурации Chrome-расширения. Он меняет архитектуру: постоянный background page заменен на сервис-воркер, а открытый перехват трафика webRequest на декларативные правила declarativeNetRequest. Без Manifest V3 расширение просто не примут в Chrome Web Store.
Обязательно ли просить host_permissions на все сайты для парсера? Нет, почти всегда достаточно activeTab плюс matches на конкретный домен в content script. Широкие host_permissions без явного обоснования, главная причина затянутого ревью и один из первых вопросов, который задаст ревьюер Google.
Почему сервис-воркер расширения перестает отвечать на запросы? Он выгружается из памяти через 30 секунд бездействия, это норма архитектуры Manifest V3, а не баг. Долгие операции нужно хранить в chrome.storage.local и периодически вызывать любой chrome API, чтобы сбросить таймер простоя.
Сколько сейчас ждать ревью Chrome Web Store? Простое расширение с activeTab может пройти автопроверку за час. Парсеры и инжекторы с scripting и host_permissions обычно попадают на ручную проверку и ждут от нескольких дней до трех недель, особенно при первой публикации с нового аккаунта.
Можно ли выполнять код на странице через инжектор без нарушения политики? Да, если использовать штатный chrome.scripting.executeScript с параметром world MAIN, а не вставлять script-теги вручную или выполнять произвольные строки через eval. Обход этого правила Google расценивает как remotely hosted code и блокирует автоматически.
Какую модель AI выбрать в Cursor для генерации парсера? Для обычного парсера хватает Claude Sonnet 4.6, для сложной архитектуры с несколькими service worker и инжекторами в разных world лучше Opus 4.8. DeepSeek V4 Pro Max подходит для черновой массовой генерации простых расширений.
Что делать, если ревью отклонили из-за permissions? Сверить каждый вызов chrome API в коде с декларацией в manifest.json, убрать все неиспользуемые permissions и переписать justification конкретнее под функцию, а не общими словами. Повторная отправка без этих правок встает в ту же очередь заново.
Глоссарий
Manifest V3, это обязательный формат конфигурации Chrome-расширения с 2023 года, описывает permissions, background и структуру файла manifest.json.
Service worker (сервис-воркер), это фоновый обработчик событий расширения, который загружается по требованию и выгружается через 30 секунд простоя.
declarativeNetRequest (DNR), это API для декларативной работы с сетевыми запросами: блокировка, редирект, изменение заголовков без чтения содержимого ответа.
Content script, это скрипт, который расширение встраивает на страницу сайта, по умолчанию работает в изолированном ISOLATED world.
Host permissions, это отдельный список доменов, к которым расширению разрешен доступ, виден и отзываем пользователем из настроек браузера.
MAIN world / ISOLATED world, это два JS-окружения для скриптов расширения: MAIN делит переменные со страницей, ISOLATED нет.
Permission justification, это текстовое обоснование каждого permission в форме публикации, которое читает ревьюер Chrome Web Store.
Если строите парсер или инжектор под конкретную задачу и хотите сразу заложить архитектуру без переделок после отказа в ревью, посмотрите разбор Cursor и Claude Code в каталоге AI-инструментов или запишитесь на консультацию к Максиму, разберем архитектуру конкретно под ваш кейс.
Обновлено: август 2026.