Должен ли файл package-lock.json быть добавлен в .gitignore?

Для блокировки версий зависимостей, установленных над проектом, команда npm install создает файл с именем package-lock.json. Это было сделано начиная с Node.js v8.0.0 и npm v5.0.0, как могут знать некоторые из вас.

Несмотря на рекомендации Node.js и npm о фиксации этого файла, некоторые вопросы, касающиеся того, когда вам следует избегать этого, также возможны. Как правило, мы участвуем в наших проектах, тем не менее, это особый вопрос.

Хотя мы должны зафиксировать файл package-lock.json по умолчанию, у нас есть конкретный случай, который мы не должны. Например, если мы хотим протестировать последнюю версию зависимостей нашего проекта, можно добавить package-lock.json в .gitignore.

Итак, вопросы таковы:

  1. Должен ли файл package-lock.json быть добавлен в .gitignore?
  2. Есть ли какая-то конкретная ситуация, в которой мы ДОЛЖНЫ или НЕ ДОЛЖНЫ это делать?

Ответ 1

Нет, package-lock.json НЕ ДОЛЖНО быть добавлено к .gitignore. Вместо этого я настоятельно советую:

  1. Добавьте package-lock.json вас в свой репозиторий контроля версий
  2. Используйте npm ci вместо npm install при создании приложения как локально, так и в конвейере развертывания.
    (Команда ci доступна с [email protected], если вы сомневаетесь, обновите свой npm с помощью:
    npm install -g npm.)

Одним из самых больших недостатков команды npm install является ее неожиданное поведение, заключающееся в том, что она может изменять package-lock.json, тогда как npm ci использует только версию в файле блокировки и выдает ошибку, если отсутствуют package-lock.json и package.json синхронизации.

Кроме того, npm ci требует наличия package-lock.json и выдает ошибку, если ее там не было. Существует серьезный пример использования для уверенности в том, что зависимости проекта разрешаются многократно и надежно на разных компьютерах.

Кроме того, npm ci очищает всю папку node_modules перед добавлением зависимостей, чтобы убедиться, что вы работаете с фактическими зависимостями, а не с локальными изменениями, и при этом работаете быстрее, чем обычные npm install.

Из package-lock.json вы получаете именно это: известное рабочее состояние.

В прошлом у меня были проекты без файлов package-lock.json/npm-shrinkwrap.json/yarn.lock, сборка которых однажды не удалась, потому что случайная зависимость получила критическое обновление. (Хотя многие библиотеки соблюдают рекомендации по управлению версиями для semvar, у вас нет гарантии, что они не сломаются при незначительном обновлении.)

Эту проблему трудно решить, так как иногда приходится догадываться, какой была последняя рабочая версия.

Что касается тестирования последних зависимостей для вашего проекта: это то, для чего npm update предназначен, и я утверждаю, что он должен выполняться разработчиком, который также выполняет тест локально, который решает проблему, если они могут возникнуть, и кто затем фиксирует измененный package-lock.json. (Если обновление не удается, они могут вернуться к последней работающей package-lock.json.)

Кроме того, я редко обновляю все зависимости одновременно (так как это тоже может потребовать дальнейшего обслуживания), но я скорее выбираю нужное обновление (например, npm update {dependency} или npm install {dependency}@2.1.3). Это еще одна причина, по которой я бы посчитал это этапом обслуживания вручную.

Если вы действительно хотите автоматизировать его, вы можете создать работу для:

  • контрольный репозиторий
  • запустить обновление npm
  • запустить тесты
    • если тесты пройдены, то зафиксируйте и отправьте в репозиторий
    • еще не удалось и сообщить о проблеме, которая будет решена вручную

Это то, что я хотел бы увидеть на сервере CI, например Дженкинс, и это не должно быть достигнуто по вышеупомянутой причине путем добавления файла в .gitignore.


Или цитировать документ npm:

Настоятельно рекомендуется зафиксировать сгенерированную блокировку пакета в контроль источника: это позволит кому-то еще в вашей команде, ваш развертывания, ваш CI/непрерывная интеграция и все, кто работает установить npm в исходный код вашего пакета, чтобы получить точно такую же зависимость дерево, на котором вы разрабатывали. Кроме того, различия из этих изменения читаются человеком и сообщат вам о любых изменениях, которые npm имеет сделано в ваши node_modules, так что вы можете заметить, если какой-либо переходный зависимости были обновлены, подняты и т.д.

А что касается разницы между npm ci и npm install:

  • Проект должен иметь существующий package-lock.json или npm-shrinkwrap.json.
  • Если зависимости в блокировке пакета не совпадают с зависимостями в package.json, npm ci выйдет с ошибкой вместо обновления пакет блокировки.
  • npm ci может устанавливать только целые проекты за раз: с помощью этой команды нельзя добавить отдельные зависимости.
  • Если node_modules уже присутствует, он будет автоматически удален до того, как npm ci начнет его установку.
  • Он никогда не будет писать в package.json или любой из пакетов-блокировок: установки по существу заморожены.