← Назад до блогу

Перезапуск Gatsby development environment

Legacy-процес Gatsby для очищення generated data, звільнення зайнятого порту й передбачуваного перезапуску dev-сервера.

Процес перезапуску Gatsby development server

Ця стаття зберігає workflow із Gatsby-версії maluk.tech. Поточний сайт працює на Next.js, але базовий урок досі актуальний: development reset має бути явним і відтворюваним.

Початкова проблема

Після зміни Gatsby-конфігурації або структури Markdown-даних dev-сервер потрібно було перезапустити, щоб GraphQL перебудував schema. Попередній процес іноді продовжував займати порт 8000, тому Gatsby пропонував запуститися на 8001, потім 8002 і так далі.

Цей workaround створював іншу проблему: вкладки браузера й CMS залишалися на старому порту. Після кількох рестартів ставало незрозуміло, яке середовище активне.

Спершу діагностика, потім зупинка процесу

Спочатку визначте, що саме слухає порт:

lsof -nP -iTCP:8000 -sTCP:LISTEN

Якщо це очікуваний застарілий dev-процес, попросіть його завершитися коректно:

kill <PID>

Примусову зупинку використовуйте лише тоді, коли процес не відповідає:

kill -9 <PID>

Не завершуйте невідомий процес лише тому, що він зайняв потрібний порт.

Автоматизація legacy Gatsby reset

В оригінальному проєкті kill-port звільняв порт 8000, а nodemon перезапускав Gatsby після зміни конфігурації:

npm install --save-dev nodemon kill-port

Перед стартом скрипт також очищав generated cache Gatsby:

{
  "scripts": {
    "dev": "nodemon --exec 'kill-port 8000 && gatsby clean && gatsby develop' --watch gatsby-node.js --watch package.json --watch gatsby-config.js"
  }
}

Після цього середовище завжди запускалося однією командою:

npm run dev

Що варто зберегти з цього рішення

Конкретні Gatsby-інструменти вже історичні. А принцип лишається сучасним:

  1. діагностувати зайнятий ресурс;
  2. зупиняти лише процес, яким ви керуєте;
  3. очищати generated state тільки після змін конфігурації або schema;
  4. фіксувати recovery sequence у project scripts;
  5. давати команді одну передбачувану команду запуску.

Автоматизація корисна, коли робить стан явним і повторюваним. Вона стає небезпечною, якщо ховає широку kill- або cleanup-команду за зручним script, тому target має бути вузьким і задокументованим.

← Назад до блогу