Делать ли я файл package-lock.json, созданный npm 5?

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

Людям, жалующимся на шум при выполнении 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 тыс. строк изменено!) из различий при просмотре онлайн при этом.

Ответ 6

Да, вы ДОЛЖНЫ:

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 вместо этого.

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

Из 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:

Настоятельно рекомендуется зафиксировать сгенерированную блокировку пакета в контроль источника: это позволит кому-то еще в вашей команде, ваш развертывания, ваш 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 или любой из пакетов-блокировок: установки по сути заморожены.

Примечание. Подобный ответ я опубликовал здесь .

Ответ 7

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

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

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

Ответ 8

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

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

npm config set package-lock false

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

Ответ 9

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

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

Плюсы: -

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

  установка npm

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

Минусы: -

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

Ответ 10

Я использую 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 жалуется на следующее:

[email protected]:introcart_wagtail$ rm package.json
[email protected]: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

[email protected]:introcart_wagtail$ rm package-lock.json 
[email protected]:introcart_wagtail$ npm run dev

> [email protected] dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

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