В чем смысл положить npm "package-lock.json" под управлением версиями?

В чем смысл положить npm package-lock.json под управлением версиями? По моему опыту, когда этот контролируемый источник файлов вызвал больше проблем и путаницы, чем повышение эффективности.

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

Есть еще несколько вопросов о блокировке пакетов:

И проблема GitHub с тонны разговора о блокировке пакетов:

Это заставляет меня думать, что по-прежнему существует распространенная неопределенность, которая нуждается в прояснении.

Согласно документам

package-lock.json автоматически создается для любых операций, где npm изменяет либо дерево node_modules, либо package.json.

Итак, почему вы хотите поместить автоматически сгенерированный файл под контроль источника?

Вышеупомянутая проблема GitHub подробно описывает, как некоторые люди в ответ на путаницу с package-lock.json меняют свой скрипт npm install на rm -f package-lock.json && npm install, что также не совсем корректно.

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

Ответ 1

По моему опыту, нет смысла размещать package-lock.json под контролем версий. Это делает управление большим слиянием/переустановкой кошмаром. Однако есть случаи, когда блокировка пакетов может быть очень полезной.

Недавно (2017/10/10) moment.js внесло изменения в незначительное обновление версии. Смысл, если кто-то должен был отправить без пакета-lock.json и имел что-то подобное в своем пакете. Json:

"moment": "^2.12.0"

Некоторые изменения, внесенные в версию 2.19.0, бесшумно проникают в ваш код почти без следа.

Вот почему, разрезав ветку, чтобы служить кандидатом на выпуск, важно:

  • удалить package-lock.json из.gitignore
  • запустить npm install для создания пакета-lock.json
  • test, qa, развертывание с помощью этой блокировки пакетов

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

Ответ 2

Создайте запись.gitattributes:

# common settings that generally should always be used with your language specific settings

# Auto detect text files and perform LF normalization
* text=auto

#
# The above will handle all files NOT found below
#

#*.svg text
*.lock binary

Затем, когда вы сливаетесь, вам нужно будет только выбрать версию и код. Думал, что вы можете столкнуться с конфликтами пакетов таким образом.

Мы смягчили это путем проверки версий в процессе сборки.