Я фиксирую файл package-lock.json, созданный npm 5?

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

Этот файл должен храниться в системе контроля версий?

Я предполагаю, что это похоже на yarn.lockи composer.lock, оба из которых должны храниться в системе контроля версий.

Да, package-lock.jsonпредназначен для проверки в системе контроля версий. Если вы используете npm 5, вы можете увидеть это в командной строке: created a lockfile as package-lock.json. You should commit this file.Согласно npm help package-lock.json:

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

Этот файл предназначен для фиксации в исходных хранилищах и предназначен для различных целей:

• Опишите единственное представление дерева зависимостей, чтобы товарищи по команде, развертывания и непрерывная интеграция гарантированно устанавливали одинаковые зависимости.

• Предоставьте пользователям возможность «путешествовать во времени» к предыдущим состояниям node_modulesбез фиксации самого каталога.

• Для облегчения видимости изменений в дереве с помощью читабельных исходных текстов контроля.

• И оптимизировать процесс установки, позволяя npm пропускать повторные разрешения метаданных для ранее установленных пакетов.

Одним из ключевых моментов package-lock.jsonявляется то, что он не может быть опубликован, и он будет игнорироваться, если будет найден в любом месте, кроме пакета верхнего уровня. Он разделяет формат с npm-shrinkwrap.json (5), который по сути является тем же файлом, но допускает публикацию. Это не рекомендуется, если только не развертывается инструмент CLI или иным образом не используется процесс публикации для создания производственных пакетов.

Если оба package-lock.jsonи npm-shrinkwrap.jsonприсутствуют в корне пакета, package-lock.jsonбудут полностью игнорироваться.

Да, он предназначен для регистрации. Я хочу предположить, что он получает свой уникальный коммит. Мы находим, что это добавляет много шума в наши различия.

Да, ты должен:

1. совершить package-lock.json.
2. использовать npm ciвместо того, чтобыnpm install создавать приложения как на CI, так и на локальной машине разработки

npm ciРабочий процесс требует существования таких package-lock.json.

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

• если package-lock.jsonи package.jsonне синхронизированы
• если package-lock.jsonотсутствует.

Следовательно, работает npm installлокально, особенно в больших командах с несколькими разработчиками, может привести к большому количеству конфликтов внутри, package-lock.jsonи разработчики решат полностью удалить package-lock.jsonвместо них.

Тем не менее, существует серьезный пример использования для уверенности в том, что зависимости проекта разрешаются многократно и надежно на разных машинах.

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

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

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

Если вы хотите добавить новую зависимость, вы все равно запускаете npm install {dependency}. Если вы хотите обновить, используйте либо npm update {dependency}или npm install ${dependendency}@{version}и подтвердите изменения package-lock.json.

Если обновление не удалось, вы можете вернуться к последней известной работе package-lock.json.

Чтобы процитировать npm doc :

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

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

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

Примечание: я разместил аналогичный ответ здесь

Да, лучше всего регистрироваться (ДА, CHECK-IN)

Я согласен, что это вызовет много шума или конфликта при просмотре diff. Но преимущества таковы:

1. гарантировать точно такую ​​же версию каждого пакета . Эта часть является наиболее важной при построении в разных средах в разное время. Вы можете использовать ^1.2.3в вашем package.json, но , как может у обеспечить каждый раз , когда npm installподберет ту же версию в вашем Dev машине и на сервере сборки, особенно те косвенные пакеты с зависимостями? Хорошо, package-lock.jsonобеспечу это. (С помощью npm ciкоторого устанавливаются пакеты на основе файла блокировки)
2. это улучшает процесс установки.
3. это помогает с новой функцией аудита npm audit fix(я думаю, что функция аудита из npm версии 6).

Я не фиксирую этот файл в своих проектах. В чем смысл ?

1. Это генерируется
2. Это является причиной ошибки целостности кода SHA1 в gitlab со сборками gitlab-ci.yml

Хотя это правда, что я никогда не использую ^ в моем package.json для библиотек, потому что у меня был плохой опыт с этим.

Людям, жалующимся на шум при выполнении git diff:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

Я использовал псевдоним:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

Чтобы игнорировать package-lock.json в diff для всего репозитория (каждый, кто его использует), вы можете добавить это в .gitattributes :

package-lock.json binary
yarn.lock binary

Это приводит к тому, что diff-файлы показывают, что «двоичные файлы a / package-lock.json и b / package-lock.json различаются при каждом изменении файла блокировки пакета. Кроме того, некоторые службы Git (в частности, GitLab, но не GitHub) также исключают эти файлы (не более 10 тыс. строк изменено!) из различий при просмотре онлайн при этом.

Да, вы можете зафиксировать этот файл. Из официальных документов npm :

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

Этот файл предназначен для фиксации в исходных хранилищах [.]

Отключить пакет-lock.json глобально

введите в своем терминале следующее:

npm config set package-lock false

это действительно работает для меня, как магия

Да, это стандартная практика для фиксации package-lock.json

Основная причина совершения package-lock.json заключается в том, что все в проекте используют одну и ту же версию пакета.

Плюсы: -

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

Минусы: -

• Это может привести к тому, что ваши запросы на тягу будут выглядеть ужасно :)

Редактировать: - установка npm не гарантирует, что все в проекте имеют одинаковую версию пакета. npm ci поможет с этим.

Я использую npm для создания уменьшенных / увеличенных css / js и для создания javascript, необходимого на страницах, обслуживаемых приложением django. В моих приложениях Javascript запускается на странице для создания анимации, иногда выполняет вызовы ajax, работает в рамках VUE и / или работает с CSS. Если package-lock.json имеет некоторый переопределенный контроль над тем, что находится в package.json, то может потребоваться, чтобы была одна версия этого файла. По моему опыту, это либо не влияет на то, что установлено с помощью npm install, либо, если это так, на сегодняшний день не оказало негативного влияния на приложения, которые я развернул, насколько мне известно. Я не использую mongodb или другие подобные приложения, которые традиционно являются тонкими клиентами.

Я удаляю package-lock.json из репозитория, поскольку npm install создает этот файл, а npm install является частью процесса развертывания на каждом сервере, на котором выполняется приложение. Контроль версий узла и npm выполняется вручную на каждом сервере, но я осторожен, что они одинаковы.

Когда npm installон запускается на сервере, он изменяет package-lock.json, и если в файл, записанный репо на сервере, вносятся изменения, при следующем развертывании НЕ БУДЕТ извлекать новые изменения из источника. То есть вы не можете развернуть, потому что pull будет перезаписывать изменения, сделанные в package-lock.json.

Вы даже не можете перезаписать локально сгенерированный package-lock.json тем, что находится в репозитории (сброс мастера жесткого происхождения), так как npm будет жаловаться, когда вы будете вводить команду, если package-lock.json не отражает то, что node_modules из-за npm install, тем самым нарушая развертывание. Теперь, если это указывает на то, что в node_modules были установлены несколько разные версии, еще раз, это никогда не вызывало у меня проблем.

Если node_modules нет в вашем репо (и не должно быть), то package-lock.json следует игнорировать.

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

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

и сборка завершается неудачно, однако при установке node_modules или применении npm для сборки js / css жалоб не возникает, если я удаляю package-lock.json

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...