Ответ 1
Нет, package-lock.json НЕ ДОЛЖНО быть добавлено к .gitignore. Вместо этого я настоятельно советую:
- Добавьте
package-lock.jsonвас в свой репозиторий контроля версий - Используйте
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.
Настоятельно рекомендуется зафиксировать сгенерированную блокировку пакета в контроль источника: это позволит кому-то еще в вашей команде, ваш развертывания, ваш 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или любой из пакетов-блокировок: установки по существу заморожены.