IHOR.DEVБАЗА_ЗНАНЬ
МЕНЮ

~/blog / Публікація / chrome-extension-publishing-checklist.md

// посібник · 3 хв читання

Контрольний список публікації розширення Chrome

Підготуйте й перевірте артефакт Chrome, узгодьте приватність та зображення Store з поведінкою й підтвердьте публічну версію.

Коротка відповідь

Публікуйте саме перевірений артефакт із правильним кореневим маніфестом, обґрунтованими дозволами, репрезентативними зображеннями та приватністю, що відповідає пакету. Завантаження, подання, схвалення й публічна доступність — різні стани. Чернетка консолі чи успішне завантаження ZIP не доводить можливості встановлення.

Після публікації перевірте публічну версію й кнопку встановлення та запишіть дату. Репозиторій фіксує LocaleStress 0.3.0 як опублікований із доступністю, перевіреною 14 жовтня 2026 року; також розрізняє публічні версії інших продуктів та їхні новіші пакети в очікуванні чи чернетках.

Практичні кроки реалізації

  1. Створіть чисту папку випуску й огляньте всі шляхи маніфесту. Приберіть залежності сервера розробки, зайві дозволи, файли налагодження й секрети. Додайте потрібні іконки та збільште версію для оновлення.
  2. Завантажте саме цю папку в окремий профіль. Перевірте перший запуск, відмови сторінок, клавіатуру, збереження параметрів, навігацію й холодний воркер. Для оновлення встановіть старі дані й перевірте міграцію, а не лише новий профіль.
  3. Створіть ZIP із вмісту папки, щоб manifest.json був у корені. Збережіть хеш і версію з результатами; після перевірок не перебудовуйте інший артефакт без перегляду змін.
  4. Заповніть опис, приватність, поширення та інструкції перевірки в консолі. Поясніть кожен дозвіл і єдину мету. За потрібної авторизації надайте робочий доступ відповідним приватним каналом. Не публікуйте тестові секрети в описі.
  5. Узгодьте знімки, оплату, приватність і підтримку з доступною поведінкою. Історія й експорт LocaleStress потребують точного пояснення; твердження «лише локально» має враховувати кожен мережевий шлях.
  6. Подайте на перевірку й збережіть статус. Усуньте конкретні зауваження перед повторенням. Після публікації встановіть публічний реліз та перевірте його версію, а не лише пакет консолі.

Це процедура випуску, а не твердження про виконані браузерні чи Store-перевірки вашого наступного пакета. Зберігайте спостереження з версією браузера, ідентичністю артефакту та рештою меж.

Приклад реалізації

Огляньте корінь перед ZIP. Команда Node перевіряє типові точки входу маніфесту; це корисна перевірка пакування, а не повний валідатор схеми чи політик Store. Запускайте з поточною папкою випуску.

import fs from "node:fs";
const manifest = JSON.parse(fs.readFileSync("manifest.json", "utf8"));
const paths = [
  manifest.action?.default_popup,
  manifest.background?.service_worker,
  manifest.options_ui?.page,
  ...Object.values(manifest.icons ?? {}),
  ...(manifest.content_scripts ?? []).flatMap(x => [...(x.js ?? []), ...(x.css ?? [])]),
].filter(Boolean);
for (const file of paths) {
  if (!fs.existsSync(file)) throw new Error(`Missing packaged file: ${file}`);
}
console.log(`Checked ${paths.length} manifest paths for ${manifest.version}`);

Розширте перевірку шляхами панелі, локалізації та web-accessible ресурсами продукту. Потім окремо огляньте архів: перевірка папки не доводить наявності файлів у ZIP.

Компроміси та альтернативи

Автоматизація підходить шляхам, хешам і визначеним тестам. Людський перегляд потрібен меті дозволів, приватності, правдивості знімків та доступу перевірки. Малий спеціалізований реліз може зменшити складність, але жоден список не гарантує схвалення чи строку.

Поширені помилки

  • Видавати успішне завантаження за публікацію.
  • Перевіряти одну папку й завантажувати інше збирання.
  • Показувати зображення майбутнього пакета як поточну поведінку.
  • Перевіряти лише нове встановлення без оновлення старих даних.

Контрольний список випуску

  • Версія, хеш і корінь архіву записані.
  • Браузерні перевірки охоплюють відмови та стан оновлення.
  • Дозволи й відповіді приватності відповідають пакету.
  • Опис, підтримка й доступ перевірки придатні.
  • Публічна версія та встановлення перевірені після публікації.

Поширені запитання

Чи схвалення доводить усі функції?

Ні. Перевірка Store й приймальні перевірки виконання продукту мають різні цілі.

Чи оголошувати pending-версію доступною?

Ні. Позначте очікування й залиште поточну перевірену встановлювану версію.

Що завершує випуск?

Перевірене публічне встановлення, точні посилання й версія продукту та збережені докази для точного артефакту.

Первинні джерела

Пов’язані посібники та приклади

Ігор Харчишин

Незалежний full-stack інженер продуктів, який пише посібники з реалізації розширень браузера та сучасних вебпродуктів на основі першоджерел.

Потрібно реалізувати це у вашому продукті?

Перегляньте відповідні приклади продуктів або поділіться контекстом розробки вебзастосунку, розширення Chrome, API чи SaaS.