Нет, 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
- run tests
- if tests passes, then commit and push to repository
- иначе не удастся и сообщить о проблеме, которую нужно решить вручную
Это то, что я бы увидел на сервере CI, например Jenkins, и этого не следует достигать по вышеупомянутой причине путем добавления файла в .gitignore.
Или чтобы процитировать документ npm:
Настоятельно рекомендуется передать сгенерированную блокировку пакета в систему управления версиями: это позволит любому члену вашей команды, вашим развертываниям, вашей CI / непрерывной интеграции и всем, кто запускает npm install в вашем источнике пакета, получить точно такое же дерево зависимостей. что вы развивались. Кроме того, различия этих изменений удобочитаемы и сообщают вам обо всех изменениях, внесенных 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 или какие-либо блокировки пакетов: установки по существу замораживаются.
person
k0pernikus
schedule
30.01.2018
