Стратегия обновления для npm install package-lock.json

NPM

npm lockfiles

Зачем нужны файлы блокировки?

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

  • Разные версии npm имеют разные алгоритмы установки.
  • Для некоторых зависимостей могут быть выпущены новые версии с момента их последней установки, поэтому зависимости будут обновлены в соответствии с версией semver-range в package.json.
  • Для зависимости зависимости может быть выпущена новая версия, и она будет обновлена, даже если вы используете спецификатор фиксированной зависимости (1.2.3 вместо ^1.2.3).

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

Правила для npm i в разных версиях npm

  • Версия npm 5.0.x: npm я буду загружать в соответствии с package-lock.json независимо от того, обновляются ли зависимости в package.json. Для этой стратегии установки кто-то поднял эту проблему -#16866, а затем превратилось в правило после 5.1.0.

  • После версии 5.1.0: при наличии новой версии зависимости в package.json npm install будет игнорировать package-lock.json, чтобы загрузить новую версию зависимости и обновить package-lock.json. В ответ на эту стратегию установки был поднят еще один вопрос -#17979, обратитесь к комментариям участника npm iarna, чтобы получить правила после версии 5.4.2.

  • После версии 5.4.2:

    • Если есть только один файл package.json, запуститеnpm iНа его основе будет сгенерирован файл package-lock.json.

    • Если версия package.json semver-range совместима с версией в package-lock.json, даже если в это время в package.json есть новая версия, выполнитеnpm iОн по-прежнему будет загружаться в соответствии с package-lock.json — практический сценарий 1.

    • Если диапазоны версий package.json изменены вручную и несовместимы с версией в package-lock.json, выполнитеnpm iКогда package-lock.json будет обновлен до совместимой версии package.json, отработайте Сценарий 2.

упражняться

версия нпм: 6.4.1

Сцена 1

  • Предположим, проект только что был клонирован из удаленного репозитория, а локальный node_modules еще не существует. Зная, что последняя версия суперагента 3.x.x — 3.8.3, затем запустите npm install для загрузки в соответствии с версией 3.5.1, указанной в package-lock.json, или для загрузки последней версии 3.x.x в соответствии с package.json?

    // package.json
"dependencies": {
    "superagent": "^3.5.1"
}

// package-lock.json
{
  "superagent": {
      "version": "3.5.1",
      "resolved": "https://npm.garenanow.com/superagent/-/superagent-3.5.1.tgz",
      "integrity": "sha1-Ck+u/aM2d3d4iDR917TSH0EMhxs=",
      "requires": {
        "component-emitter": "^1.2.0",
        "cookiejar": "^2.0.6",
        "debug": "^2.2.0",
        "extend": "^3.0.0",
        "form-data": "^2.1.1",
        "formidable": "^1.1.1",
        "methods": "^1.1.1",
        "mime": "^1.3.4",
        "qs": "^6.1.0",
        "readable-stream": "^2.0.5"
      }
    },
}

    Вывод: загрузка есть3.5.1. В настоящее время package.json и package-lock.json существуют одновременно, и версия package.json^3.5.1, версия package-lock.json3.5.1, а загруженный в текущем node_modules тоже3.5.1.

сцена 2
  • Затем сценарий 1, а затем вручную измените версию суперагента в package.json на^5.1.0, а затем выполнить npm i и обнаружить, что версия superagent в package-lock.json стала независимо от того, удалены существующие node_modules или нет.5.1.0, в node_modules тоже становится5.1.0.

Ссылаться на

npm ci

представлять

  • Это: непрерывная интеграция.
  • версия npm не нижеv5.7.1.
  • Эта команда аналогична npm install, за исключением того, что она предназначена для использования в автоматизированных средах, таких как среды тестирования интеграции, живые среды или в любой ситуации, когда вы хотите обеспечить чистую установку зависимостей. Это может быть намного быстрее, чем обычная установка npm, если пропустить некоторые функции, ориентированные на пользователя. Кроме того, она более строгая, чем обычная установка, и может обнаруживать ошибки или несоответствия из-за добавочной установки локальной среды.

Различия между npm ci и npm install

  • В проекте должен присутствовать package-lock.json или npm-shrinkwrap.json.
  • Если зависимости в файлах блокировки и package.json не совпадают, npm ci завершит работу с ошибкой вместо обновления файлов блокировки.
  • NPM Ci может установить только зависимость всего проекта и не может установить одну зависимость.
  • Если node_modules уже существует, он будет автоматически удален перед началом установки npm ci.
  • npm ci никогда не изменяет package.json и package-lock.json.

Пополнить

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

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

Ссылаться на

Пополнить

Недавно я разрабатывал новое требование, и мне нужно было использовать echarts.После загрузки echarts с помощью npm install echarts -S я обнаружил, что разрешенные поля многих других пакетов в package-lock.json стали register.npmjs.org. детали следующие:

  • Сначала запросите локальный источник npm:npm config get registry

  • Затем загрузите графики:npm install echarts -S; package-lock.json будет обновлен. До и после сравнения части package-lock.json: слева — до обновления, справа — после обновления, главное изменение в том, что разрешенное поле изменилось с npm.garenanow.com на register.npmjs.org.

    Скриншот раздела package.json @babel/generator в node_modules:

    Скриншот раздела package.json @babel/helper-annotate-as-pure в node_modules:

  • Вывод: Поле _resolved указано в package.json каждого пакета в node_modules.При обновлении package-lock.json это поле будет скопировано вместо источника, указанного текущим npm. Весьма вероятно, что при инициализации проекта и выполнении npm install в начале исходник -Registry.npmjs.org.Даже если вы обновите исходник позже, поле _resolved скачанного пакета не изменится. Эту проблему можно решить удалением всего node_modules и повторной загрузкой.Конечно, лучше всего создать файл .npmrc в корневой директории проекта и указать в нем источник npm, чтобы члены команды использовали единый npm исходник, чтобы не было конфликтов в package-lock.json при вытягивании кода.

Ссылки на другие статьи

Путь TypeScript

Пошаговое создание и публикация пакета TypeScript NPM

Стратегия обновления для npm install package-lock.json

[Перевод] Языковые настройки браузера

Date.prototype.toLocaleString()

Категории