it-roy-ru.com

Какой смысл ставить npm "package-lock.json" под контроль версий?

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

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

Есть несколько других SO вопросов о блокировке пакетов:

И проблема 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? Когда мучительная боль разрешения конфликтов слияния в этом файле начинает окупаться?

14
Cumulo Nimbus

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

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

"moment": "^2.12.0"

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

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

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

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

8
Cumulo Nimbus

Создайте запись .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

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

Мы уменьшили это, проверив версии в процессе сборки.

3
Fitch

IMO package-lock.json (или yarn-lock.json) должен всегда быть привязан к системе контроля версий. За исключением конфликтов слияния/перебазировки (которые в значительной степени смягчаются yarn BTW - вы можете yarn install mid-rebase для автоматического устранения проблем), это лучшая гарантия того, что код на этом коммите будет правильно собираться и работать после новой проверки и установки ,.

0
linguamachina