Package lock json: Page not found · GitHub Pages — Программирование на Python и Objective-C в Mac OS

Содержание

javascript — Для чего нужен package-lock.json?

Доброе время суток.
Я почитал документацию к NPM, почитал форумы, но всё равно до конца не совсем понимаю, смысловую нагрузку этого файла.

Вот то что описано на npm документации:

Этот файл предназначен для фиксации в исходных хранилищах и
предназначен для различных целей:
1) Описывает единственное представление дерева зависимостей, чтобы товарищи
по команде, разворачивая проект гарантированно
установил одинаковые зависимости.
2) Предоставьте пользователям возможность «путешествовать во времени» к
предыдущим состояниям node_modules без фиксации самого каталога.
3) Для облегчения большей видимости изменений в дереве с помощью читаемых
исходных текстов контроля.
4) И оптимизировать процесс установки, позволяя npm пропускать
повторяющиеся установленные пакеты.

Вопрос сразу по 1 пункту, ибо у меня package.json и package-lock.json не в гит игноре! Они комитятся.
И как написано в той же документашке, когда мы делаем npm i, пакетный менеджер устанавливает зависимости, которые описаны в файле package.json.
И скачав очередную библиотеку мы идем внутрь неё и устанавливаем её зависимости (и так рекурсивно).
На данном этапе в package-lock.json просто выводится информация какие внутренние зависимости основных библиотек мы скачали.
Как оно помогает «гарантированно установил одинаковые зависимости» ?

И это всё полностью вытекает из 3 пункта.

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

Верно ли я все понимаю? Пожалуйста, поправьте!

Разбираемся с lock-файлами в NPM 5 | by Andrey Melikhov | devSchacht

Перевод статьи Jiří Pospíšil: Understanding lock files in NPM 5. Опубликовано с разрешения автора.

Следующая мажорная версия NPM приносит ряд улучшений по сравнению с предыдущими версиями с точки зрения скорости, безопасности и множества других отличных вещей. Однако самым необычным с точки зрения пользователя является новый lock-файл. Фактически, теперь у нас несколько lock-файлов: «старый» npm-shrinkwrap.json и новый package-lock.json. Подробнее об этом чуть ниже, а пока небольшая вводная для непосвящённых. Файл package.json описывает зависимости верхнего уровня от других пакетов с помощью semver. Каждый пакет может, в свою очередь, зависеть от других пакетов и так далее, тому подобное. Lock-файл — это моментальный снимок всего дерева зависимостей, включающий все пакеты и их установленные версии.

В отличие от предыдущей версии, lock-файл теперь включает в себя поле целостности (integrity), использующее Subresource Integrity (SRI) для проверки того, что установливаемый пакет не был подменён или иным образом недействителен. В настоящее время он поддерживает SHA-1 для пакетов, опубликованных с помощью NPM предыдущей версии, и SHA-512 для текущей.

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

Lock-файл теперь также содержит версию формата, указанную в поле lockfileVersion, установленную в значение 1. Это значит, что при будущих обновлениях формата не придётся угадывать, какую конкретную версию использует lock-файл. Предыдущий формат по-прежнему поддерживается и распознается как версия 0.

{
"name": "package-name",
"version": "1.0.0",
"lockfileVersion": 1,
"dependencies": {
"cacache": {
"version": "9.2.6",
"resolved": "https://registry.npmjs.org/cacache/-/cacache-9.2.6.tgz",
"integrity": "sha512-YK0Z5Np5t755edPL6gfdCeGxtU0rcW/DBhYhYVDckT+7AFkCCtedf2zru5NRbBLFk6e7Agi/RaqTOAfiaipUfg=="
},
"duplexify": {
"version": "3.5.0",
"resolved": "https://registry.npmjs.org/duplexify/-/duplexify-3.5.0.tgz",
"integrity": "sha1-GqdzAC4VeEV+nZ1KULDMquvL1gQ=",
"dependencies": {
"end-of-stream": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/end-of-stream/-/end-of-stream-1.0.0.tgz",
"integrity": "sha1-1FlucCc0qT5A6a+GQxnqvZn/Lw4="
},

Возможно, вы заметили, что поле resolved все еще присутствует в файле и указывает на определенный URI. Обратите внимание, однако, что NPM теперь может определить (на основе параметров в .npmrc), что система настроена на использование другого реестра, и если это так, он будет прозрачно использовать его вместо указанного. Это хорошо работает с полем целостности, потому что теперь, пока пакет соответствует сигнатуре, не имеет значения, откуда он пришел.

Еще одна вещь, о которой стоит упомянуть: lock-файл точно описывает физическое дерево каталогов в директории node_modules. Преимущество этого заключается в том, что даже если разные разработчики используют разные версии NPM, они все равно должны иметь не только одни и те же версии зависимостей, но и то же самое дерево каталогов. Этим NPM 5 отличается от других пакетных менеджеров, таких как Yarn. Yarn описывает только зависимости между отдельными пакетами в плоском формате и опирается на свою текущую реализацию для создания структуры каталогов. Это означает, что при изменении внутреннего алгоритма структура также изменится. Если вы хотите узнать больше о различиях между Yarn и NPM 5, когда дело доходит до lock-файла, почитайте про детерминизм Yarn.

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

Возможно, вы думаете, что то же самое уже может быть достигнуто с помощью npm shrinkwrap и её npm-shrinkwrap.json. И вы правы. Причиной создания нового файла является попытка лучшего донесения мысли о том, что NPM действительно поддерживает блокировку зависимостей, что, видимо, было проблемой в прошлом.

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

Также вам может быть интересно узнать, что происходит, когда вы запускаете npm shrinkwrap в каталоге, который уже содержит package-lock.json. Ответ довольно прост: NPM просто переименует package-lock.json в npm-shrinkwrap.json. Это возможно, потому что формат файлов совпадает.

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

Обобщая:

NPM автоматически создаст package-lock.json при установке пакетов. Если уже присутствует npm-shrinkwrap.json, то будет использован он (и при необходимости обновлён).
Новый package-lock.json никогда не публикуется и должен быть добавлен в вашу систему контроля версий.
Запуск npm shrinkwrap в случае наличия package-lock.json просто переименует его в npm-shrinkwrap.json.
Когда оба файла присутствуют по какой-либо причине, package-lock.json будет проигнорирован.

Это здорово, но как выбрать: использовать новый lock-файл вместо старого доброго shrinkwrap или наоборот? Обычно это зависит от типа пакета, над которым вы работаете.

Если вы работаете с библиотекой (то есть пакетом, от которого будут зависеть другие пакеты), вы должны использовать новый lock-файл. Альтернативой является использование shrinkwrap, но убедитесь, что он никогда не будет опубликован вместе с пакетом (новый lock-файл защищён от публикации автоматически). Почему бы не опубликовать shrinkwrap? Это связано с тем, что NPM обрабатывает shrinkwrap-файлы, которые он находит в пакетах, и поскольку shrinkwrap всегда указывает на конкретные версию отдельных пакетов, вы не сможете воспользоваться тем фактом, что NPM может использовать один и тот же пакет для разрешения зависимостей нескольких пакетов, если диапазон semver позволяет это.1.0.0. Каждый раз устанавливается версия, указанная в lock-файле и всё прекрасно работает. А что происходит, если публикуется новая версия зависимости, случайно нарушившая semver, и ваш пакет ломается из-за этого?

К сожалению, вы не сможете заметить этого до тех пор, пока не появится отчет об ошибке. Без каких-либо lock-файлов в репозитории ваша сборка завершится неудачно, по крайней мере, в CI, поскольку она всегда будет устанавливать последние версии зависимостей и, таким образом, запускать тесты с новой сломанной версией (при условии, что сборка выполняется периодически, а не только для PR). Однако при наличии lock-файла CI-сервер всегда будет устанавливать рабочую заблокированную версию.

Есть несколько вариантов решения этой проблемы. Во-первых, вы можете пожертвовать точной воспроизводимостью и не добавлять lock-файл в свою систему контроля версий. Во-вторых, вы можете создать отдельную конфигурацию сборки, которая будет запускать npm update перед запуском тестов. В-третьих, вы просто удаляете lock-файл перед запуском тестов. Как на самом деле поступать с сломанной зависимостью, когда она была обнаружена, это отдельная тема, главным образом потому, что semver, реализованный NPM, не имеет концепции указания разрешения широкого диапазона и также не имеет черного списка конкретных версий.

Это, конечно, ставит вопрос о том, стоит ли добавлять lock-файл в систему управления версиями при работе с библиотеками. Однако следует иметь в виду, что lock-файл содержит не только runtime-зависимости, но и зависимости для разработки (dev dependencies). В этом смысле работа над библиотекой аналогична работе над приложением (смотрим следующий раздел).

Хорошо, что насчёт пакетов, используемых конечными пользователями для запуска в консоли или в комплекте исполняемых файлов? В этом случае пакет — это конечный результат, приложение, и вы хотите, чтобы конечные пользователи всегда получали точные зависимости, которые вы имели при публикации. Здесь вы захотите использовать shrinkwrap и не забудьте также опубликовать его с пакетом, чтобы NPM использовал его во время установки. Помните, что вы всегда можете проверить, как выглядит пакет, если он будет опубликован с использованием npm pack.

Обратите внимание, что указание на определенные версии зависимостей в package.json — не лучшая идея, потому что вы хотите, чтобы конечные пользователи получили то же самое дерево зависимостей, включая все подзависимости. Конкретная версия в package.json гарантирует версию только на верхнем уровне.

Lock-файлы npm / Блог компании ДомКлик / Хабр

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

Как мы уже определили, npm берёт на входе манифест проекта (файл package.json) и описанные в нем зависимости, а на выходе мы получаем локально сгенерированную директорию node_modules, в которой содержатся все установленные зависимости.

Не будем сейчас касаться деталей структуры node_modules, однако замечу, что установленные пакеты не всегда имеют плоскую структуру, а могут в отдельных случаях формировать некую иерархию, когда один или несколько пакетов вложены в другой пакет. Как правило, это происходит, когда в дереве зависимостей присутствует один и тот же пакет, но разных версий. При этом сама структура в файловой системе не детерминирована на 100 %, и может зависеть, в том числе, от порядка установки зависимостей.

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

Вы помните, что список зависимостей в манифесте проекта содержит диапазон версий semver, что позволяет обновлять зависимости? Получается, что установка зависимостей в разное время будет приводить к разным результатам, потому что содержимое npm registry постоянно меняется, регулярно выходят новые пакеты. Кроме того, поскольку мы имеем дело с деревом зависимостей, то транзитивные зависимости (зависимости ваших зависимостей) тоже будут меняться во времени.

А еще может возникнуть ситуация, когда содержимое пакета, лежащего в npm registry, было заменено без обновления версии. Это называется мутацией пакетов и запрещено в официальном npm registry, однако в частных реестрах вполне возможно. А что, если содержимое пакета было заменено злоумышленником, чтобы внести в код какие-то закладки?

Учитывая все эти факторы, становится очевидно, что структура данных в директории node_modules очень нестабильна и может меняться во времени, даже если ваш манифест при этом остается нетронутым.

Наивно было бы попытаться зафиксировать зависимости, прописывая строгие версии в манифесте проекта (вместо диапазонов semver): как мы рассмотрели выше, это не даст существенных результатов, потому что транзитивные зависимости всё равно будут обновляться. Да и другие факторы не перестанут влиять на установку зависимостей. Кроме того, если вы заморозите ваши прямые зависимости, то получится ситуация, когда более старые версии будут работать с более свежими версиями транзитивных зависимостей, и потенциально это повышает вероятность проблем с интеграцией.

А теперь представьте, что у нас в проекте есть конвейер CI/CD и специальный сервер, который собирает, тестирует и выкатывает приложения в разные среды выполнения. Как правило, такие решения привязываются к ID коммита в Git (или к Git-тегам), и на каждый коммит система генерирует готовый к выкатке артефакт (архив с готовыми для выполнения файлами). Таким образом, на вход конвейера поступает код из Git-репозитория, версионированный через ID коммита, а на выходе вы получаете протестированный и готовый к выкатке артефакт. В идеале, это должно работать как чистая функция (pure function): если вы пересоберёте коммит, созданный несколько месяцев назад, то должны получить на выходе тот же самый артефакт. Однако мы не можем хранить содержимое node_modules в Git, и получается, что после клонирования репозитория нам необходимо вызывать установку зависимостей из реестра npm. А, как мы уже выяснили, этот процесс довольно нестабилен и привязан к глобальному состоянию экосистемы (содержимому npm registry, версиям npm и т. д.). Получается, что npm вносит хаос в наш конвейер CI/CD и мы уже не можем получить одинаковую сборку по ID коммита.

Чтобы предотвратить все описанные выше проблемы и сделать использование зависимостей гораздо более стабильным, npm (как и любой другой современный менеджер) предлагает специальный механизм заморозки зависимостей. Работает это автоматически и прямо из коробки: впервые вызывая команду npm install, npm не только устанавливает все зависимости и создаёт директорию node_modules, он также создает специальный файл package-lock.json. Этот файл называется lock-файлом и содержит в себе полную информацию обо всех установленных зависимостях, включая их точные версии, URL npm registry, из которого был скачан пакет, а также SHA-хэш самого архива с пакетом. Помимо прочего, lock-файл npm описывает еще и порядок установки зависимостей, и их вложенность в файловой системе.

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

Чтобы использовать преимущества lock-файла, его необходимо добавить в систему контроля версий. Таким образом, вы строго привяжете полное дерево зависимостей к коммитам в Git. Это будет гарантировать стабильное воспроизводство сборок в вашей системе CI/CD и позволит надежно «путешествовать во времени».

Кроме того, каждый разработчик, который склонирует Git-репозиторий к себе на машину, получит точно такое же дерево зависимостей, как и у вас. Это устранит известную проблему из разряда «странно, а у меня всё работает» (“it works on my machine”).

Npm генерирует lock-файл полностью автоматически на основе данных из манифеста проекта, глобального состояния npm registry и алгоритма установки зависимостей npm. Однако содержимое файла вполне читаемо человеком и может быть использовано даже на этапе code review. Diff lock-файла покажет, какие зависимости в дереве были обновлены, какие были удалены, а какие добавлены. Наверное, нет смысла изучать изменения этого файла при каждом обновлении, но при обнаружении каких-то деградаций это может сильно помочь в поиске виновного пакета и сэкономить вам кучу времени. Но чтобы это работал эффективнее и размер изменений был минимальным, я рекомендую обновлять зависимости как можно чаще (гораздо проще выявить проблему, если у вас обновилось три пакета в дереве зависимостей, а не сотня).

Давайте теперь рассмотрим содержимое файла package-lock.json в тестовом проекте, где установлена только одна зависимость — express.

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

package-lock.json

{
  "name": "test",
  "version": "1.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "express": {
      "version": "4.17.1",
      "resolved": "https://registry.npmjs.org/express/-/express-4.17.1.tgz",
      "integrity": "sha512-mHJ9O79RqluphRr…7xlEMXTnYt4g==",
      "requires": {
        "debug": "2.6.9",
        "send": "0.17.1"
      }
    },
    "debug": {
      "version": "2.6.9",
      "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz",
      "integrity": "sha512-bC7ElrdJaJnPbAP…eAPVMNcKGsHMA==",
      "requires": {
        "ms": "2.0.0"
      }
    },
    "ms": {
      "version": "2.0.0",
      "resolved": "https://registry.npmjs.org/ms/-/ms-2.0.0.tgz",
      "integrity": "sha1-VgiurfwAvmwpAd9fmGF4jeDVl8g="
    },
    "send": {
      "version": "0.17.1",
      "resolved": "https://registry.npmjs.org/send/-/send-0.17.1.tgz",
      "integrity": "sha512-BsVKsiGcQMFwT8U…cNuE3V4fT9sAg==",
      "requires": {
        "debug": "2.6.9",
        "depd": "~1.1.2",
        "destroy": "~1.0.4",
        "encodeurl": "~1.0.2",
        "escape-html": "~1.0.3",
        "etag": "~1.8.1",
        "fresh": "0.5.2",
        "http-errors": "~1.7.2",
        "mime": "1.6.0",
        "ms": "2.1.1",
        "on-finished": "~2.3.0",
        "range-parser": "~1.2.1",
        "statuses": "~1.5.0"
      },
      "dependencies": {
        "ms": {
          "version": "2.1.1",
          "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.1.tgz",
          "integrity": "sha512-tgp+dl5cGk28utY…YaD/kOWhYQvyg=="
        }
      }
    }
  }
}

Итак, давайте разбираться. Начнем с основных корневых свойств:

name и version — тут всё просто, это название и версия проекта из его манифеста на момент создания lock-файла.

lockfileVersion — это версия формата, в котором представлен lock-файл. Она нужна для расширяемости, если разработчики npm в будущем придумают какой-то новый формат хранения.

dependencies — полное плоское дерево зависимостей вашего проекта; объект, в котором ключ это название пакета, а значение — дескриптор.

Дескриптор каждой отдельно взятой зависимости выглядит следующим образом:

version — точная версия пакета на момент установки.

resolved — URL пакета в реестре npm, откуда он был скачан.

integrity — SHA-хэш пакета; проверочная сумма, которая позволяет убедиться, что в пакет не было внесено изменений как в процессе скачивания, так и на стороне хранилища (защита от мутации). Это очень важный элемент безопасности при работе с npm, который гарантирует, что злоумышленник не сможет как-то вмешаться в код пакета. При обнаружении несоответствия вызов npm install будет прерван с ошибкой.

requires — объект, описывающий транзитивные зависимости (копируется из поля dependencies манифеста стороннего пакета). Ключ является названием пакета, а значение — диапазоном версий semver.

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

dev — если true, то эта зависимость является только зависимостью для разработки (необходимо для раздельной установки зависимостей).

Обратите внимание, что в примере выше пакет express (наша прямая зависимость) зависит от пакета debug, а тот, в свою очередь, от [email protected]. В то же время, пакет send также зависит от ms, но уже версии 2.1.1. Получается, что в директории node_modules пакет ms должен быть установлен два раза (разных версий), но, в силу сложившихся правил в Node.js, два пакета разных версий не могут быть установлены в корне. По этой причине одна версия устанавливается в корень ([email protected]), а вторая — в поддиректорию пакета send ([email protected]). Это решение как раз и отражено в lock-файле. В том числе благодаря этому достигается стабильность директории node_modules.

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

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

Если несколько разработчиков трудятся в одной ветке и используют lock-файлы, то в какой-то момент может возникнуть merge-конфликт в Git. В этом случае достаточно просто устранить конфликты в файле манифеста (если они есть), а потом выполнить npm install: менеджер пакетов автоматически исправит конфликты в lock-файле.

Если вам не хочется править конфликты в lock-файлах вручную, то можете установить специальный merge-драйвер для Git, который умеет работать с npm. Это позволит исправлять конфликты в файле package-lock.json автоматически. Однако, если конфликт возникнет в манифесте, то вам всё равно будет необходимо исправить конфликт вручную, а потом вызвать npm install.

Установить merge-драйвер для npm можно следующим образом:

npx npm-merge-driver install -g

При возникновении конфликта при вызове команд Git в консоли будет выведено:

npm WARN conflict A git conflict was detected in package-lock.json.
Attempting to auto-resolve. Auto-merging package-lock.json

Для работы с lock-файлами не требуется каких-то особых действий со стороны разработчика, npm автоматически обновляет lock-файл, когда в этом есть необходимость. Например, если вы вызываете команду npm install lodash, то помимо того, что npm добавит новую зависимость в манифест и установит её, он автоматически обновит lock-файл. Таким образом, npm всегда следит, чтобы lock-файл был в актуальном состоянии.

Однако если вы вносите изменения в манифест проекта вручную, например, добавляя новую зависимость, то возникает «дрифт» (рассинхронизация) между манифестом и lock-файлом. Менеджер пакетов достаточно умён, чтобы обнаружить этот дрифт: когда вы вызовете команду npm install, npm проанализирует актуальность lock-файла, и если он устарел, то менеджер пакетов автоматически обновит lock-файл, используя данные из манифеста.

Как я сказал выше, если npm обнаружит отставание lock-файла от манифеста, то это приведет к обновлению lock-файла и установке зависимостей из манифеста. Такое поведение очень удобно при разработке, но совершенно непригодно, и даже опасно в контексте конвейера CI/CD, потому что может привести к неожиданным результатам из-за слетевшей блокировки зависимостей.

Чтобы этого не происходило, разработчики npm добавили специальную команду npm ci. В отличие от npm install, эта команда никогда не обновляет lock-файл. Более того, если в проекте отсутствует или устарел lock-файл, то npm ci вернет код ошибки и прервет выполнение конвейера, гарантируя, что ничего плохого не случится (принцип Fail-fast). Кроме того, npm ci полностью удаляет директорию node_modules перед установкой зависимостей, что гарантирует установку на чистый лист.

По этой причине никогда не следует использовать команду npm install в рамках конвейера CI/CD, обязательно используйте npm ci вместо нее. Идите и проверьте это прямо сейчас! (я подожду).

Давайте теперь поговорим про особенности использования lock-файлов в проектах разных типов. Первое, о чём стоит сказать: файл package-lock.json не публикуется в npm registry. Это означает, что если вы публикуете свой пакет в реестр npm (библиотека), то содержимое вашего lock-файла не будет оказывать влияния на дерево зависимостей при установке вашего пакета в чей-то проект. В этом случае играет роль только содержимое вашего манифеста. Это и хорошо: если бы каждая библиотека замораживала свои зависимости, то дерево зависимостей в конечном проекте было бы ещё больше (куда уж больше?) и содержало огромное количество дублей. Адекватно управлять зависимостями стало бы невозможно.

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

Как я сказал выше, использовать это решение для библиотек очень вредно, поэтому не стоит этого делать. Однако, оно может быть полезно, если вы разрабатываете программу на Node.js, которая должна выполняться на компьютере пользователя (например, аналог webpack, gulp, create-react-app и т. д.). Если программа устанавливается преимущественно глобально на компьютере пользователя (npm i -g), то использование shrinkwrap-файла гарантирует, что на машине пользователя программа будет иметь те же зависимости, что и на вашей машине. Так что, если у вас есть явные причины опасаться дрифта зависимостей в вашей программе, то вы можете воспользоваться npm shrinkwrap. В остальных случаях я не рекомендовал бы использовать эту команду.

Кстати, файл npm-shrinkwrap.json имеет приоритет над файлом package-lock.json. В проекте достаточно только одного файла.

Важным этапом в работе над проектом библиотеки является его тестирование. Дело в том, что вы полностью не контролируете внешние условия, в которых будет вызываться ваша библиотека. Даже если вы зафиксируете прямые зависимости, вы не сможете зафиксировать транзитивные (разве что будете использовать shrinkwrap, но мы уже выяснили, что это плохая практика).

По этой причине вы не можете гарантировать среду, однако можете протестировать работу библиотеки со свежими версиями всех зависимостей, чтобы убедиться, что в новых и свежих проектах ничего не сломается. Однако, если вы будете использовать lock-файл в вашем проекте, то он будет постоянно оттягивать версии ваших зависимостей назад, не давая вам полноценно тестировать совместимость с самыми свежими версиями всех зависимостей (которые наверняка будут у ваших пользователей). Либо вам придется постоянно вызывать глубокий npm update перед каждым тестом.

Руководствуясь этим, некоторые разработчики советует вообще не использовать lock-файлы для проектов библиотек. Однако, я считаю это слишком радикальным советом. Дело в том, что помимо продуктовых runtime-зависимостей вашего пакета существуют еще и dev-зависимости. Если вы откажетесь от lock-файла, то ваши dev-зависимости выйдут из-под контроля, то есть вы потеряете некий островок стабильности.

Более подходящим решением, на мой взгляд, была бы реорганизация конвейера CI/CD таким образом, чтобы код библиотеки тестировался в проекте без использования lock-файла, путем установки самых свежих доступных зависимостей. Собирать же пакет (если требуется) можно и с участием lock-файла (для этого можно использовать два разных этапа в вашем CI/CD конвейере).

У многих разработчиков lock-файлы вызывают чувство раздражения, видимо, из-за непонимания их предназначения или особенностей их работы. Такие разработчики норовят добавить package-lock.json в .gitignore или вообще настроить npm, чтобы запретить генерирование lock-файлов. При этом они (часто сами того не понимая) жертвуют стабильностью и безопасностью своего приложения, а также теряют достаточно мощный инструмент отслеживания изменений зависимостей в проекте. Часто эти же люди начинают строго прописывать версии зависимостей в основном манифесте, чтобы как-то компенсировать эту нестабильность, не отдавая себе отчета в том, что это не решает проблему, а только создает иллюзию её решения. Я уже не говорю о том, что они используют инструмент не по назначению, теряя гибкость разработки, которая обеспечивается, в том числе, и механизмами семантического версионирования.

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

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

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

С другой стороны, если вы не будете полгода обновлять зависимости, то потом сделать это будет очень сложно, потому что крупное обновление очень сложно разделить на маленькие части. Вы получите огромный ворох изменений разной степени тяжести, а в случае возникновения проблемы (а она, скорее всего, придет не одна) выявить точное место будет гораздо сложнее (diff здесь уже будет бесполезен в силу его гигантского размера).

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

Мы рассмотрели столь важный инструмент повышения надежности и безопасности управления зависимостями, как lock-файлы npm. Использование этого механизма позволит вам существенно повысить стабильность работы вашего проекта и улучшить качество и удобство разработки.

В следующем посте я еще дальше углублюсь в вопросы безопасности npm.

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

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

Удаление `package-lock.json` для быстрого разрешения конфликтов

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

Есть ли проблема с удалением файла и тем, чтобы npm воссоздал его таким образом, а не разрешал конфликты вручную?

javascript

node.js

npm

package-lock.json

Поделиться

Источник

John Mutuma

10 января 2019 в 07:50

3 ответа

Да, это может и повлияет на весь проект очень плохо.

если ваша команда не запускает npm install после каждого git pull , вы все используете разные версии зависимостей. Поэтому он заканчивается на «but it works for me!!» и «Я не понимаю, почему мой код не работает для вас»
даже если вся команда работает npm install , это все равно не означает, что все в порядке. в какой-то момент вы можете обнаружить, что ваш проект действует по-другому. в той части, которую вы не меняли годами. и после (вероятно, довольно болезненной) отладки вы обнаружите, что это связано с тем, что зависимость 3-го уровня обновилась для следующей основной версии, и это привело к некоторым критическим изменениям.

Вывод: никогда не удаляйте package-lock.json . в вашем случае вам лучше поступить следующим образом:

Подход 1

отмените изменения в package-lock.json
stash ваши изменения
pull самая последняя версия кода
запустите npm install для всех зависимостей, которые необходимо добавить
открепите свои изменения.

Подход 2

запустить слияние
для разрешения конфликта выберите «their changes only» стратегию на package-lock.json
запустите npm install , чтобы зависимости, которые вы хотите добавить, также были включены в package-lock.json
завершите фиксацией фиксации(коммита) слияния.

PS да, для зависимостей первого уровня, если мы указываем их без диапазонов (например, "react": "16.12.0"), мы получаем одни и те же версии при каждом запуске npm install . Но мы не можем сказать то же самое о зависимостях глубиной 2+ уровня (зависимостях, на которые полагаются наши зависимости), поэтому package-lock.json действительно важен для стабильности.

Поделиться

skyboyer

10 января 2019 в 11:03

Да, это может иметь плохие побочные эффекты, может быть, не очень часто, но, например, у вас может быть package.1.0.0″ , а раньше у вас было "moduleX": "1.0.0" в package-lock.json .

Удалив package-lock.json и запустив npm install , вы можете обновиться до версии 1.0.999 из moduleX, не зная об этом, и, возможно, они создали ошибку или сделали обратное изменение (не следуя семантическому управлению версиями).

Во всяком случае, для этого уже есть стандартное решение.

Исправьте конфликт внутри package.json
Запуск: npm install --package-lock-only

https://docs.npmjs.com/настройка-npm/пакет-locks.html#resolving-lockfile-конфликты

Поделиться

OZZIE

05 июня 2020 в 07:35

Я знаю, что это старый вопрос, но для будущих искателей вы также можете использовать npm-merge-driver, которые пытаются автоматически решить проблемы слияния связанных файлов npm.

Просто установите его глобально npx npm-merge-driver install --global . Подробнее об этом вы можете прочитать здесь npm-merge-driver

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

Поделиться

Taha

25 сентября 2019 в 12:19

Следует ли добавить файл package-lock.json в файл .gitignore?
Чтобы заблокировать версии зависимостей, установленных над проектом, команда npm install создает файл с именем package-lock.json . Это было сделано с Node.js v8.0.0 и npm v5.0.0 , как некоторые из вас, возможно, знают. Несмотря на рекомендации Node.js и npm о фиксации(коммита) этого файла,…
Никакого эффекта при выполнении git diff — ‘:(exclude)package-lock.json’
Я хочу сделать diff, но без пакета-lock.json, который огромен и является сгенерированным файлом, так что ничего интересного для меня там нет. Я пробовал оба : git diff — ‘:(exclude)package-lock.json’ git diff — ‘:!package-lock.json’ но у него просто нулевой выход. Что я делаю не так? Я бегу git…

package-lock.json — Русский — it-swarm.com.ru

package-lock.json — Русский — it-swarm.com.ru

it-swarm.com.ru

Нужны ли мне как package-lock.json, так и package.json?

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

Создайте package.json из package-lock.json

Ошибка потенциальной уязвимости Github для модуля узла hoek

Как исправить уязвимый пакет npm в моем package-lock.json, который не указан в package.json?

В чем разница между npm-shrinkwrap.json и package-lock.json?

npm5 эквивалентно флагу —pure-lockfile для пряжи?

Почему «npm install» переписывает package-lock.json?

npm install не создает новый пакет-lock.json

Есть ли способ заставить npm сгенерировать package-lock.json?

Почему package-lock.json изменил хэш целостности с sha1 на sha512?

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

Ошибка: локальный файл рабочей области (‘angular.json’) не найден

Диапазон Caret и package-lock.json: как получить с ними последние версии без взлома?

Package-lock.json — требует зависимости от

Что такое свойство целостности внутри файла yarn.lock?

Как npm опубликовать определенную папку, но как корень пакета

Буфер без круговой блокировки

Служба распределенной блокировки

Изменить цвета подсветки синтаксиса Emacs

Есть ли готовая к производству очередь без блокировки или хэш-реализация в C++?

Многопоточность без блокировки — для настоящих экспертов

стоимость атомной операции

Получение «Превышено время ожидания блокировки; попробуйте перезапустить транзакцию», даже если я не использую транзакцию

Отключить экран на Android

В чем разница между Gemfile и Gemfile.lock в Ruby на Rails

Понимание файла Gemfile.lock

Как отключить автоблокировку iPhone/iPad, когда приложение находится в режиме переднего плана?

Не блокируемая множественная очередь производителей / потребителей в C ++ 11

Gemfile.lock содержит конфликты слияния

планирование будильника на каждую секунду в Android 5.1

Atomic shared_ptr для однозначного списка без блокировки

Как сделать так, чтобы Android-устройство всегда было в активном режиме?

Функция Samsung «Оптимизация приложений» убивает фоновые приложения через 3 дня

Ваш пакет заблокирован для rake (12.0.0), но эта версия не может быть найдена ни в одном из источников, перечисленных в вашем Gemfile.

Использование очереди Boost.Lockfree медленнее, чем использование мьютексов

Гарантии прогресса без блокировок

Как просмотреть иерархическую структуру пакета в обозревателе пакетов Eclipse

Что это значит: ошибка [INSTALL_FAILED_CONTAINER_ERROR]?

Не включайте зависимости из файла packages.config при создании пакета NuGet

Произошла ошибка при попытке восстановить пакеты. Пожалуйста, попробуйте еще раз

[A] System.Web.WebPages.Razor.Configuration.HostSection не может быть приведен к … web.config проблема

Как импортировать конкретную версию пакета, используя go get?

Включить восстановление пакета NuGet в Visual Studio 2013

NuGet не может найти существующий пакет

Где sdkman устанавливает пакеты?

Несанкционированный пакет nuget из Visual Studio Team Services с использованием ядра asp.) в package.json?

npm устанавливает частные репозитории github по зависимости в package.json

Создайте настройки запуска WebStorm из раздела «scripts» package.json

Как использовать частное Github репо в качестве зависимости от npm

Изменить рабочий каталог для скриптов npm

Корневой каталог в package.json

Заставьте `npm install —save` добавить строгую версию в package.json

NPM: как просто запустить постинсталляцию?

Ошибка запуска скрипта при запуске npm start

что я должен указать в поле лицензии моего package.json, если мой код предназначен только для компании, в которой я работаю?

Проект Node.js без package.json

«неожиданный импорт токенов» в Nodejs5 и babel?

Локально установленный глоток не работает в командной строке?

Как отобразить версию приложения в Angular?

Как настроить package.json для запуска сценария eslint

Как добавить пользовательский скрипт в файл package.json, который запускает файл javascript?

Не удается заставить композитор «путь» хранилище работать

Как установить только «devDependencies», используя npm

NPM, package.json — как добавить зависимость с «@» в имени

Как указать путь `package.json` к npm?

Ошибка зависимости от узла

Сборка .exe файла в .NET Core RC2

Как использовать сценарии package.json для копирования файлов с определенным расширением

npm package.json основная и структура проекта

npm update ничего не делает

Как вы используете свойства ‘files’ и ‘directoryies’ в package.json?

Принудительная установка пряжи вместо npm для модуля Node?

Как синхронизировать `yarn.lock` с` package.json`?

Для чего нужно поле «module» package.json?

Поле ‘browser’ не содержит допустимой конфигурации псевдонима

Не удается установить пакеты NuGet, для которых требуется Newtonsoft.Json.10.0.1, в Visual Studio 2015

Закрытый репозиторий bitbucket в package.json с версией

Почему (и как я могу FIx) ESLint import / no-extranous-dependencies Сбои в установленных пакетах?

Почему модули Node попадают в папку .staging?

Что такое тестовая команда при создании package.json?

Как мне решить, входит ли @ types / * в «зависимости» или «devDependencies»?

Определить личный реестр в package.json

Ошибка: EPERM: операция не разрешена, отсоедините ‘D: \ Sources \ ** \ node_modules \ fsevents \ node_modules \ abbrev \ package.json’

«Uncaught TypeError: React.createClass не является функцией» в файле Render.js (электронное приложение)

Переместите модуль из devDependencies в зависимости в npm package.json

Как я могу запустить несколько скриптов npm одновременно?

Развертывание Angular 5 + Nodejs Express App для Heroku

Как я могу ссылаться на версию пакета в скрипте npm?

Angular5: polyfills.ts & \ main.ts отсутствует в компиляции TypeScript

Что Webpack 4 ожидает от пакета с побочными эффектами: false

Не удается найти модуль «@ angular-devkit / build-angular»

Запустите ng build —prod с другими настройками среды

Content dated before 2011-04-08 (UTC) is licensed under CC BY-SA 2.5. Content dated from 2011-04-08 up to but not including 2018-05-02 (UTC) is licensed under CC BY-SA 3.0. Content dated on or after 2018-05-02 (UTC) is licensed under CC BY-SA 4.0. | Privacy

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

Description

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

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

Опишите единое представление дерева зависимостей таким образом,чтобы товарищи по команде,развертывание и непрерывная интеграция гарантировали установку точно таких же зависимостей.
Предоставьте пользователям возможность «путешествовать во времени» к предыдущим состояниям node_modules без необходимости фиксации самого каталога.
Повышение наглядности изменений в дереве с помощью читаемых различий в контроле исходных текстов.
Оптимизируйте процесс установки,позволяя npm пропускать повторные разрешения метаданных для ранее установленных пакетов.
Начиная с npm v7, файлы блокировки содержат достаточно информации, чтобы получить полное представление о дереве пакетов, уменьшая необходимость чтения файлов package.json и позволяя значительно улучшить производительность.

package-lock.json против npm-shrinkwrap.json

Оба этих файла имеют одинаковый формат и выполняют схожие функции в корне проекта.

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

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

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

Hidden Lockfiles

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

Все папки пакетов, на которые он ссылается, существуют в иерархии node_modules .
В иерархии node_modules нет папок пакетов , которые не указаны в файле блокировки.
Измененное время файла по крайней мере такое же недавнее,как и у всех папок пакета,на которые он ссылается.

То есть,скрытый lockfile будет актуален только в том случае,если он был создан в рамках последнего обновления дерева пакетов.Если другой CLI каким-либо образом изменит дерево,это будет обнаружено,и скрытый файл блокировки будет проигнорирован.

Обратите внимание , что это можно вручную изменить содержимое из пакета таким образом , что измененное время папки пакета не изменяется. Например, если вы добавляете файл в node_modules/foo/lib/bar.js , то время изменения на node_modules/foo не будет отражать это изменение. Если вы вручную редактируете файлы в node_modules , обычно лучше удалить файл в node_modules/.package-lock.json .

Поскольку скрытый файл блокировки игнорируется более старыми версиями npm, он не содержит возможностей обратной совместимости, присутствующих в «обычных» файлах блокировки. То есть это lockfileVersion: 3 , а не lockfileVersion: 2 .

Работа со старыми файлами блокировки

Когда npm обнаруживает файл блокировки из npm v6 или ранее во время процесса установки пакета, он автоматически обновляется для получения недостающей информации либо из дерева node_modules , либо (в случае пустых деревьев node_modules или очень старых форматов файлов блокировки) из реестра npm.

Формат файла

name

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

version

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

lockfileVersion

Целочисленная версия, начиная с 1 с номера версии этого документа, семантика которого использовалась при создании этого package-lock.json .

Обратите внимание, что формат файла значительно изменился в npm v7, чтобы отслеживать информацию, которую в противном случае потребовалось бы искать в node_modules или реестре npm. Файлы блокировки, созданные npm v7, будут содержать lockfileVersion: 2 .

Версия не указана:»древний» shrinkwrap-файл из версии npm,предшествующей npm v5.
1 : версия файла блокировки, используемая в npm v5 и v6.
2 : версия файла блокировки, используемая npm v7, которая обратно совместима с файлами блокировки v1.
3 : версия файла блокировки, используемая npm v7, без возможности обратной совместимости. Это используется для скрытого node_modules/.package-lock.json блокировки в node_modules / .package-lock.json и, вероятно, будет использоваться в будущей версии npm, когда поддержка npm v6 перестанет быть актуальной.

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

packages

Это объект,который сопоставляет местоположение пакета с объектом,содержащим информацию об этом пакете.

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

Дескрипторы пакетов имеют следующие поля:

версия: версия, найденная в package.json
resolved:Место,откуда пакет был фактически разрешен.В случае пакетов,взятых из реестра,это будет ссылка на tarball.В случае git-зависимостей это будет полный git url с commit sha.В случае зависимостей от ссылок это будет местоположение целевой ссылки.
целостность: sha512 стандартной целостности субресурсов sha512 или sha1 для артефакта, распакованного в этом месте.
ссылка:Флаг,указывающий,что это символическая ссылка.Если он присутствует,другие поля не указываются,поскольку цель ссылки также будет включена в файл блокировки.
dev, необязательно, devOptional: если пакет является строго частью дерева devDependencies , тогда dev будет истинным. Если это строго часть дерева optionalDependencies , то будет установлено значение optional . Если это и dev зависимость и optional зависимость не-Дева зависимость, то devOptional будет установлено. ( optional зависимость зависимости dev будет иметь как dev ,так и optional .)
inBundle:Флаг,указывающий на то,что пакет является зависимостью,входящей в пакет.
hasInstallScript: флаг, указывающий , что пакет имеет preinstall , install или postinstall сценарий.
hasShrinkwrap: флаг, указывающий, что в пакете есть файл npm-shrinkwrap.json .
bin, лицензия, движки, зависимости, optionalDependencies: поля из package.json

dependencies

Устаревшие данные для поддержки версий npm, использующих lockfileVersion: 1 . Это отображение имен пакетов на объекты зависимостей. Поскольку структура объекта строго иерархическая, в некоторых случаях сложно представить зависимости символьных ссылок.

npm v7 полностью игнорирует этот раздел, если присутствует раздел packages , но поддерживает его в актуальном состоянии, чтобы поддерживать переключение между npm v6 и npm v7.

Объекты зависимостей имеют следующие поля:

version:спецификатор,который варьируется в зависимости от характера пакета и используется при получении его новой копии.
- связные зависимости:Независимо от источника,это номер версии,который носит чисто информационный характер.
- источники реестра: это номер версии. (например, 1.2.3 )
- git sources: это спецификатор git с разрешенной фиксацией. (например, git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e )
- http tarball sources: это URL-адрес tarball. (например, https://example.com/example-1.3.0.tgz )
- локальные источники tarball: это URL файла tarball. (например, file:///opt/storage/example-1.3.0.tgz )
- локальные источники ссылок: это URL-адрес файла ссылки. (например, file:libs/our-module )
целостность: sha512 стандартной целостности субресурсов sha512 или sha1 для артефакта, распакованного в этом месте. Для зависимостей git это фиксация sha.
разрешен:Для источников реестра это путь к tarball относительно URL реестра.Если URL tarball не находится на том же сервере,что и URL реестра,то это полный URL.
bundled:Если true,то это зависимость в комплекте и будет установлена родительским модулем.При установке этот модуль будет извлечен из родительского модуля на этапе извлечения,а не установлен как отдельная зависимость.
dev:Если true,то эта зависимость является либо зависимостью разработки ТОЛЬКО от модуля верхнего уровня,либо переходной зависимостью от него.Это значение равно false для зависимостей,которые одновременно являются зависимостью разработки верхнего уровня и переходной зависимостью зависимости верхнего уровня,не связанной с разработкой.
optional:Если true,то эта зависимость является либо необязательной зависимостью ТОЛЬКО модуля верхнего уровня,либо транзитивной зависимостью одного из них.Это значение равно false для зависимостей,которые являются как необязательной зависимостью верхнего уровня,так и транзитивной зависимостью неопциональной зависимости верхнего уровня.
требует: это отображение имени модуля в версию. Это список всего, что требуется для этого модуля, независимо от того, где он будет установлен. Версия должна соответствовать через обычные правила сопоставления зависимости либо в наших dependencies либо на более высоком уровне, чем мы.
зависимости:Зависимости этой зависимости,точно такие же,как и на верхнем уровне.

См.также

Роль package-lock.json, настройка и использование кармы

После npm 5.0 после установки npm будет package-lock.json. Что это за функция?

1. Заблокируйте номер версии пакета во время установки и загрузите его в git, чтобы гарантировать согласованность всех зависимых пакетов.

2. package-lock.json — это файл, сгенерированный во время `npm install` для записи конкретного источника и номера версии каждого пакета npm, фактически установленного в текущем состоянии.

3. Какая от этого польза? Поскольку npm является менеджером для управления зависимостями между пакетами, он позволяет разработчикам отмечать зависимости своих проектов от библиотек npm в середине pacakge.ОпределеноОбратно (новые) совместимые зависимости, Это означает, что если версия типов / узла больше 8.0.33 и совпадает с основным номером версии (8), последняя версия пакета библиотеки типов / узлов может быть загружена. Например, конкретная версия, которая действительно может быть загружена при запуске npm install, 8.0.35.

В большинстве случаев не возникает проблем при загрузке последнего пакета библиотеки в новую зависимость совместимости, но поскольку npm — это мир с открытым исходным кодом, семантика версии каждого пакета библиотеки может быть разной, и некоторые разработчики пакетов библиотеки не следуют этому строгому принципу. : Интерфейс того же пакета библиотеки с тем же основным номером версии соответствует требованиям совместимости. В это время у пользователя болит голова: в одной и той же базе кода nodejs, в разное время или в разных источниках загрузки npm версии загруженных пакетов зависимых библиотек могут быть разными, поэтому характеристики поведения пакетов зависимых библиотек также Разные, иногда даже совершенно несовместимые.

решить:

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

4. Недостатки package.json

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

5. Различные решения проблем зависимости установки:

Что, если при установке в пакете есть ошибка, и нам нужно обновить ее позже?

Раньше: раньше можно было напрямую изменить версию в package.json, а затем установить npm.

Сейчас: но это не поддерживается после версии 5, потому что версия заблокирована в package-lock.json, поэтому мы можем только npm install xxx @ xxx для обновления наших зависимостей, а затем package-lock.json также может Обновите соответственно.

Например:

Если я установил jquery 2.1.4 и обновил package.json и package-lock.json из git, может ли моя установка npm перезаписать зависимости в node_modules?

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

1. Определение

Karma — это не среда тестирования и не библиотека утверждений.

Karma — это инструмент тестирования, инструмент, который позволяет выполнять код JavaScript в нескольких реальных браузерах, предоставляя разработчикам эффективную среду тестирования.

Код может быть разработан для выполнения на стороне браузера, и некоторые ошибки могут не быть обнаружены в тесте в среде узла; кроме того, у браузера есть проблемы с совместимостью, карма предоставляет средства для автоматического запуска вашего кода в нескольких браузерах (Chrome, Firefox, т.е. и т. д.). Если ваш код будет работать только на стороне узла, вам не нужно использовать карму.

Когда мне следует использовать Карму?

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

Два, конфигурация

Сначала установите глобальную карму, чтобы инициализировать конфигурацию кармы

image.png

Какую среду тестирования вы хотите использовать?
(1) Jasmine (BDD, обеспечивает вывод в Интернете)
(2) Mocha
① Можно протестировать как простые функции JavaScript, так и асинхронный код, поскольку асинхронность является одной из характеристик JavaScript.
② Все тесты можно запускать автоматически или только определенные тесты.
③Он может поддерживать до, после, beforeEach и afterEach для написания кода инициализации
(3) Qunit（Jquery）
(4) Nodeunit (предоставляет простые асинхронные модульные тесты для node.js и браузеров.)
(5) Nunit (интеграция в VS)
Вы хотите использовать require.js? Нет (модульный инструмент спецификации AMD)
Вы хотите автоматически захватывать какие-либо браузеры?
(1) Chrome
(2) ChromeHeadless (запускать Google Chrome в режиме без головы — в режиме браузера без головы, используется для автоматического тестирования и серверов, не требующих визуального пользовательского интерфейса и командной строки)
(3) ChromeCanary (две версии Chrome могут быть установлены / запущены одновременно, установлены по разным путям, с использованием проприетарных значков, сочетаний клавиш и т. д., которые необходимо обновлять отдельно и сравнивать с существующими Chrome работает без помех)
(4) Firefox
(5) Safari
(6) PhantomJS (основан на JavaScript API webkit, он использует QtWebKit в качестве основной функции браузера, а webkit используется для компиляции, объяснения и выполнения кода JavaScript)
(7) Opera
(8) IE
Где исходные файлы и тестовые файлы? »./tests/unit/*.spec.js’
Следует ли исключить какие-либо файлы, включенные в предыдущий шаблон?
Вы хотите, чтобы Karma контролировала все файлы и запускала тесты изменений?

Конфигурация Karma.conf.js (с именем:Conf, а не config)

// Karma configuration
// Сгенерировано 4 апреля 2019 г., 09:59:06 GMT + 0800 (китайское стандартное время)

const webpackConfig =  require('@vue/cli-service/webpack.config.js')

module.exports = function(config) {
  config.set({
         // Основной путь, используемый в файлах и исключающих атрибуты
    basePath: '',

         // Доступные фреймы: https://npmjs.org/browse/keyword/karma-adapter
    frameworks: ['mocha'],

         // Список файлов, которые нужно загрузить в браузер
    files: [
      './tests/unit/*.spec.js'
    ],

         // Список исключенных файлов
    exclude: [
      'node_modules'
    ],

         // Обработка совпадающих файлов перед использованием в браузере
         // Доступный препроцессор: https://npmjs.org/browse/keyword/karma-preprocessor
    preprocessors: {
        '**/*.spec.js': ['webpack']
    },

         // Используем репортер результатов теста
         // Возможные значения: «точки», «прогресс»
         // Доступные репортеры: https://npmjs.org/browse/keyword/karma-reporter
    reporters: ['progress'],

         // Номер сервисного порта
    port: 9876,

         // конфигурация webpack
    webpack: webpackConfig,

         // Включение или отключение цвета в выходном отчете или журнале
    colors: true,

         // уровень журнала
         // Возможные значения: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
    logLevel: config.LOG_INFO,

         // Включение или отключение автоматического обнаружения изменений файлов для тестирования
    autoWatch: true,

         // Тестируем запущенный браузер
    // available browser launchers: https://npmjs.org/browse/keyword/karma-launcher
    browsers: ['Chrome'],

         // Включение или отключение режима непрерывной интеграции
         // Если установлено значение true, Karma откроет браузер, выполнит тест и, наконец, выйдет
    singleRun: false,

         // Уровень параллелизма (количество запущенных браузеров)
    concurrency: Infinity
  })
}

webpack.test.config.js

var path = require("path")
var webpack = require("webpack")

function resolve(dir) {
    return path.join(__dirname, '..', dir)
}

var webpackConfig = {
    module: {
        rules: [
            // babel-loader
            {
                test: /\.js$/,
                use: 'babel-loader',
                include: [resolve('src'), resolve('test')]
            },
            // vue loader
            {
                test: /\.vue$/,
                use: [{
                    loader: 'vue-loader',
                    options: {
                        loaders: {
                            js: 'babel-loader'
                        },
                    }
                }]
            },
        ]
    },

    resolve: {
        extensions: ['.js', '.vue', '.json'],
        alias: {
            'vue$': 'vue/dist/vue.esm.js',
            '@': resolve('src'),
        }
    },

    plugins: [
        new webpack.DefinePlugin({
            'process.env': {
                NODE_ENV: '"production"'
            }
        })
    ]
}

module.exports = webpackConfig

Компилятор Babel-loader js, который переводит js, не поддерживаемые браузером, в js, поддерживаемые браузером
основной пакет

babel-core: сам переводчик babel, который предоставляет API перевода Babel, например babel.transform, для перевода кода. Babel-loader, такой как webpack, вызывает эти API для завершения процесса перевода.
babylon: лексический парсер для js
babel-traverse: используется для обхода AST (абстрактное синтаксическое дерево, если вы хотите знать, проверьте принцип компиляции самостоятельно), в основном для плагина
babel-generator: генерировать код на основе AST

Перевести код ES6 в код ES5

image.png

В-третьих, установите зависимости кармы

npm install --save-dev @vue/test-utils karma karma-chrome-launcher karma-mocha karma-sourcemap-loader karma-spec-reporter karma-webpack mocha

image.png

Четыре, используйте

Добавьте скрипты в package.json

"test:karma": "karma start"

Тогда беги

npm run test:karma

Или беги напрямую

karma start

image.png

Без кармы (также с использованием мокко)

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

Я использую 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,
и если есть изменения в файле, который записан репозиторием на сервере, следующее развертывание WONT позволит вам получить новые изменения из источника. То есть
вы не можете развернуть, потому что запрос перезапишет изменения, внесенные в package-lock.json.

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

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

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

  Джейсон @ локальный: introcart_wagtail $ rm package.json
jason @ localhost: introcart_wagtail $ npm установить
npm WARN saveError ENOENT: нет такого файла или каталога, откройте '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

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

  Джейсон @ локальный: introcart_wagtail $ rm package-lock.json
Джейсон @ localhost: introcart_wagtail $ npm запустить dev

> [email protected] dev / home / jason / webapps / introcart_devtools / introcart_wagtail
> NODE_ENV = веб-пакет разработки --progress --colors --watch --mode = разработка

 10% здание 0/1 модули 1 активны ...

Разница между `npm update` и` remove package-lock.json` плюс `npm install`?

В package-lock.json в основном косвенные зависимости заблокированы.Косвенные зависимости означают те зависимости, которые не указаны в package.json вашего проекта, но являются зависимостями ваших зависимостей.

При вызове npm update --dev некоторые зависимости обновляются в пакете package.json . После обновления записей вызывается установка, эта установка обновляет в package-lock.json те третьи стороны, которые связаны с измененными в package.json .Это означает, что как прямые, так и косвенные зависимости обновляются в файле package-lock.json . Но только для тех, что были модифицированы в package.json .
Третьи стороны, которые остались прежними в package.json , не будут затронуты в package-lock.json . (Их прямая и косвенная зависимости остаются неизменными.)

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

Давайте посмотрим на это на примере.

В package-lock.json у нас есть косвенная зависимость от tslib: 1.9.0 .

  "цлиб": {
  "версия": "1.9.0",
  "решено": "https://registry.npmjs.org/tslib/-/tslib-1.9.0.tgz",
  "целостность": "sha512-f / qGG2tUkrISBlQZEjEqoZ3B2 + npJjIf04h2wuAv9iA8i04Icp + 61KRXxFdha22670NJopsZCIjhC3SnjPRKrQ =="
},

tslib — это зависимость всех модулей Angular, которые указаны непосредственно в пакете .4.9.3 ", "транспортир": "~ 5.4.0", "ts-node": "~ 5.0.1", "цлинт": "~ 5.9.1" }

Если мы вызовем npm update --dev , будут внесены следующие изменения:

  + [email protected]
+ [email protected]
+ [email protected]
+ [email protected]
+ [email protected]
+ [email protected]
+ [email protected]
+ @ типы / жасмин @ 3.3.16
+ @ типы / jasminewd2 @ 2.0.8
+ [email protected]
+ [email protected]

Мы видим, что в пакете .json Угловые зависимости не трогаем. Отсюда следует, что tslib также остался в версии 1.9.0 в пакете package-lock.json .

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

Заключение

Таким образом, разница в том, что в случае npm update --dev обновляются только те прямые и косвенные зависимости, которые были связаны с измененными в package.json . Но в случае rm package-lock.json и npm install все косвенные зависимости могут измениться.

Почему вам следует использовать package-lock.json

В этой статье мы рассмотрим package-lock.json , почему он важен и как его лучше всего использовать вместе с NPM CLI в повседневной жизни. .

История

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

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

Издатель этого модуля (без использования package-lock.json ) должен установить express версии 4.16.4, поскольку они установили последнюю версию.

Если express опубликовал новую версию к моменту загрузки этого модуля и попытки установить зависимости от него, я могу загрузить последнюю версию.

Символ каретки говорит нам именно об этом.

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

То же самое могло случиться в производственной среде, и вы не понимали, почему это дает сбой.

До версии 5 NPM вы использовали бы термоусадочную пленку . Он отличается от package-lock.json тем, что его разрешено публиковать вместе с вашим модулем в реестре NPM, а package-lock.json — нет.

Если все участники могут использовать NPM + 5, лучше всего использовать package-lock.json для неопубликованных проектов.

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

Итак, package-lock.json будет описывать точное дерево зависимостей, установленное в данный момент. Формат описан на странице документации NPM.

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

Всегда фиксируйте package-lock.json в VCS, чтобы отслеживать точные деревья зависимостей в любой момент времени.

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

package.json и package-lock.json

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

Однако это происходит только в том случае, если вы используете CLI NPM для внесения изменений. Если вы вручную измените package.json , не ждите, что package-lock.json обновится. Всегда используйте команды интерфейса командной строки, такие как установить , удалить и т. Д.

Как использовать NPM CLI

NPM автоматически сгенерирует блокировку пакета .json , когда вы впервые используете его в новом проекте.

Затем вы можете использовать NPM как обычно.

установка npm (с конкретными модулями в качестве аргументов)

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

Рассмотрим следующий пример:

 npm установить экспресс body-parser cors

npm install (без аргументов)

install попытается установить все зависимости, относящиеся к package-lock.json .

Ключевым моментом здесь является то, что install может изменить package-lock.json , если он зарегистрирует, что он устарел.

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

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

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

npm удалить

Аналогично , установите , но с именами модулей, которые нужно удалить в качестве аргументов. Это изменит как package.json , так и package-lock.Символ указывает NPM проверить, есть ли более новая версия в области действия 1.X.X , и, если есть, установить ее. Точно так же символы ~ будут обновлены только до исправлений, или 1.4.X .

Вы также можете опустить специальный символ и оставить фиксированную версию, что делает package-lock.json менее полезным (но не бесполезным).

нпм ci

ci установит все зависимости, относящиеся к package-lock.json аналогично установить . Ключевое отличие здесь в том, что он не изменит package-lock.json ни при каких обстоятельствах.

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

Заключение

Помните об этих важных выводах при использовании package-lock.json :

Не используйте npm install без аргументов для получения зависимостей — используйте для этого npm ci .Вы можете использовать npm install для установки определенных зависимостей.

Используйте npm ci везде, когда вам нужно только локальное дерево зависимостей — даже в вашей локальной среде разработки.

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

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

Дополнительные ссылки

заглушка

LogRocket: полная видимость ваших веб-приложений

LogRocket — это решение для мониторинга внешних приложений, которое позволяет воспроизводить проблемы, как если бы они произошли в вашем собственном браузере. Вместо того, чтобы угадывать, почему происходят ошибки, или запрашивать у пользователей снимки экрана и дампы журнала, LogRocket позволяет воспроизвести сеанс, чтобы быстро понять, что пошло не так. Он отлично работает с любым приложением, независимо от фреймворка, и имеет плагины для регистрации дополнительного контекста из Redux, Vuex и @ ngrx / store.

Помимо регистрации действий и состояния Redux, LogRocket записывает журналы консоли, ошибки JavaScript, трассировки стека, сетевые запросы / ответы с заголовками и телами, метаданные браузера и пользовательские журналы. Он также использует DOM для записи HTML и CSS на странице, воссоздавая видео с идеальным пикселем даже для самых сложных одностраничных приложений.

Попробуйте бесплатно.

Что такое пакетная блокировка json? Файлы Lockfiles для пакетов пряжи и npm

Что такое package-lock.json?

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

Файл блокировки пакета сначала вводится в проект, когда в этом проекте выполняется новая установка зависимостей. Во время установки все дерево зависимостей вычисляется и сохраняется в файле блокировки вместе с метаданными о каждой зависимости, например:

Версия пакета, которая должна быть установлена 
Хэш целостности, используемый для подтверждения того, что пакет не был подделан с помощью
Разрешенное расположение в реестре, указывающее, откуда был получен этот пакет и откуда он должен быть получен для будущих установок

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

Файлы блокировки

предназначены для закрепления или блокировки всех версий всего дерева зависимостей во время создания файла блокировки.1.0.0 , то две отдельные установки, выполненные в разное время, могут получить разные версии dummy-pkg . Это может произойти, если пользователь устанавливает dummy-pkg , который получил версию 1.0.0, а затем через несколько минут этот пакет выпускает новую версию 1.0.1. После этого второй пользователь, выполняющий установку в проекте, получит dummy-pkg версии 1.0.1 вместо версии 1.0.0.

Использование файлов блокировки гарантирует, что установки останутся идентичными и воспроизводимыми во всем дереве зависимостей, для разных пользователей, например, членов команды, работающих вместе, и для разных систем, например, при выполнении сборки CI.

Как работают файлы блокировки?

Существует два файла блокировки пакетов, которые можно идентифицировать для большей части экосистемы npm:

Пряжа Замок пряжи
npm’s package-lock.json

Нет ничего лучше хорошей блок-схемы, чтобы объяснить, как используются эти два:

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

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

Напильники с термоусадочной пленкой

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

Важно отметить, что yarn и npm отличаются тем, как они работают с пакетами, имеющими npm-shrinkwrap.json , а именно:

npm всегда будет помещать зависимости, указанные в npm-shrinkwrap.json , на собственный уровень пакета в папку node_modules / и не будет пытаться сгладить это дерево.

Пряжа

никогда не учитывает npm-shrinkwrap.json и полностью игнорирует его.

Для чего нужен файл в термоусадочную пленку? Что ж, это позволяет разработчикам библиотек определять и курировать зависимости своих собственных библиотек, чтобы отправлять известные версии.Однако это требует тщательного обслуживания всего дерева зависимостей. Кроме того, если используется сжатый файл, нет необходимости в существовании какого-либо другого файла блокировки в системе управления версиями. Хорошим примером библиотеки, использующей такой подход, является хорошо известный проект hapijs.

`Напильники для дрейфующих замков`

Файлы блокировки

появляются, когда разработчики взаимодействуют с проектом, например, добавляя зависимость или устанавливая зависимости для исходного клона проекта. Обычно разработчики добавляют или удаляют зависимости от проекта во время цикла разработки, но что произойдет, если они внесут изменения в пакет ?json и забыли зафиксировать соответствующий файл блокировки?

Когда проект package.json не синхронизирован с файлом блокировки, менеджеры пакетов, такие как npm и yarn, попытаются согласовать разницу и сгенерировать новый манифест. Хотя это звучит неплохо, на самом деле это рецепт для проблем, если это произойдет во время CI.

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

Таким образом, рекомендуется посоветовать менеджерам пакетов использовать файл блокировки при установке зависимостей, например:

 
$ yarn install --frozen-lock файл
$ npm ci

`Lockfiles для приложений и библиотек`

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

Существует консенсус в отношении проектов приложений, использующих файл блокировки.Библиотеки как проекты - не столько. Это почему?

Главный аргумент против наличия файлов блокировки в библиотеках состоит в том, что это вызовет несоответствие в зависимостях, которые потребители фактически устанавливают с библиотекой. Из-за этого несоответствия разработчики пакетов не заметят критических сборок.

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

Лично я считаю, что проекты библиотек ничем не отличаются и должны включать файл блокировки для совместной работы членов команды и воспроизводимых сборок.

Позвольте мне предложить усовершенствование - если вы действительно беспокоитесь о том, что зависимости вашей библиотеки будут нарушены для ваших пользователей, вы можете установить две разные сборки CI для устранения этих проблем:

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

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

`Что такое package-lock.json?`

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

`Как package-lock.json управляет деревом зависимостей`

пакет-замок.json - это файл, созданный npm (начиная с v5 2017), и он блокирует зависимости пакетов и их подчиненные зависимости. Он отслеживает только зависимости верхнего уровня и связанные с ними версии. Звучит просто, правда? Хотя каждая из этих зависимостей верхнего уровня также может иметь свои собственные зависимости, и каждая из них также может иметь свои собственные зависимости и так далее. Эта взаимосвязь между всеми зависимостями и подчиненными зависимостями в проекте называется деревом зависимостей . Дерево зависимостей представляет каждый модуль, от которого зависит наш проект, и требуемую версию.

💰 Начните свое облачное путешествие с 100 долларов США в виде бесплатных кредитов

с участием DigitalOcean.

Установка зависимости с помощью npm фактически извлекает все необходимые зависимости и устанавливает их в папку node_modules / . Файл package-lock.json - это снимок всего нашего дерева зависимостей и вся информация, необходимая npm для воссоздания состояния папки node_modules / . Кроме того, если присутствует файл package-lock.json , npm install установит точные указанные версии.

package-lock.json не предназначен для чтения человеком и не предназначен для редактирования вручную. Интерфейс командной строки npm генерирует и управляет им автоматически.

`Трек package-lock.json`

Файл package-lock.json необходимо передать в систему управления версиями (GIT), чтобы каждый раз использовать одно и то же дерево зависимостей. Преимущество фиксации файла блокировки пакета для управления версиями заключается в отслеживании состояния папки node_modules / без необходимости передавать саму папку в систему контроля версий. Никогда не фиксируйте папку узлов-модулей. Он не предназначен для фиксации, он слишком большой, и его состояние уже отслеживается.

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

`термоусадочная пленка, нпм`

Блокировка зависимостей - не новая концепция в Node.js или в мире программирования. Файл package-lock ведет себя почти так же, как уже существующий npm-shrinkwrap.json , который заключался в том, как заблокировать пакет до npm v5. Единственное отличие состоит в том, что package-lock.json игнорируется npm при публикации в реестре NPM. Если вы хотите заблокировать свои зависимости, при публикации пакета вы должны использовать npm-shrinkwrap.json . У вас должен быть только один из этих файлов в корневом каталоге. Если присутствуют оба npm-shrinkwrap имеет преимущество.Рекомендуемый вариант использования npm-shrinkwrap.json - это приложения, развернутые в процессе публикации в реестре NPM.

Чтобы создать файл npm-shrinkwrap, запустите npm shrinkwrap . Эта команда переименовывает ваш package-lock в npm-shrinkwrap . Файлы функционально такие же. npm-shrinkwrap следует использовать при публикации в реестр NPM.

`TL; DR`

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

Спасибо за чтение, и если у вас есть вопросов , используйте функцию comment или отправьте мне сообщение @mariokandut .

Если вы хотите узнать больше об узле Node , ознакомьтесь с этими руководствами по узлам.

`Ссылки (и большое спасибо):`

NPM package-lock, NPM shrinkwrap, Node, HeyNode

`package-lock.json vs package.json: Но что за черт package-lock.json?`

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

package-lock.json - чрезвычайно важный файл, который предназначен для того, чтобы спасти вас от большого количества boom boom bam bam 🔥 в ваших репозиториях.

Итак, прежде чем мы перейдем к блокировке пакетов.json поговорим о семантическом управлении версиями и package.json.

Semantic versioning или SemVer - идеальный способ управления версиями пакетов. Обычно они записываются как 1.4.5 (major.minor.patch)

1а. Исправление ошибки / версия патча

Включает исправления ошибок / орфографические ошибки в документации и т. Д.

1б. Дополнительная версия

Включает в себя добавления функций или API, которые не нарушают ничего из старых версий. Так что все, что работает на v1.1.0 должен работать и с версией 1.9.0.

1с. Основная версия

Включает версию, которая ломается. Он может включать удаление API или изменение имен функций, поэтому все, что работает на v1.0.0, может не обязательно работать на v2.0.0

package.json - это файл, содержащий информацию о вашем проекте (имя, версию и т. Д.), И в нем перечислены пакеты, от которых зависит ваш проект.

Как вы можете видеть на картинке выше, после каждой зависимости, указанной в package. он будет обновлен до последней версии патча)

Однако это может стать серьезной проблемой, если разработчики пакетов нарушат любую из функций младшей версии, так как это может привести к поломке вашего приложения.

Итак, позже npm выпустил новый файл под названием package-lock.json, чтобы избежать таких сценариев.

package-lock.json просто избегает этого общего поведения установки обновленной младшей версии, поэтому, когда кто-то клонирует ваше репо и запускает npm install на своем компьютере. NPM рассмотрит блокировку пакетов. и ~ из package.json.

Кроме того, он содержит некоторую другую метаинформацию, которая экономит время на выборку этих данных из npm во время установки npm.

Дополнительную информацию о package-lock.json можно найти в блоге npm.

Спасибо, что прочитали это!

Надеюсь, это было полезно 🎉 🙂

РЕДАКТИРОВАТЬ: Итак, читая комментарии, я подумал, что должен также объяснить, как изменяется package-lock.json, поэтому вот один из написанных мной ответов, который, я думаю, всем следует пройти через

EDIT2: Цитата из комментария Кэт Марчан
(https: // dev.to / zkat / comment / epbj) Это она написала npm ci и добавила package-lock.json в NPM

Устранение конфликтов в package-lock.json | Блог TkDodo

Я бы хотел не тратить столько времени на разрешение конфликтов git, сколько сейчас.

Это громоздко. Это подвержено ошибкам. Это просто не весело.

Одна вещь, которая может стоить дорого, если сделана неправильно, — это разрешение конфликтов в сгенерированных файлах, таких как package-lock.json.
Обычно это происходит, когда две ветки добавляют или обновляют зависимость.Затем результат блокировки пакета меняется, и тот, кто первым объединит свой PR с основным, тот счастливчик, который избежал этих конфликтов.
Это почти как гонка.

Итак, вы обновляете свой PR с помощью базовой ветки, и git показывает вам огромное количество конфликтов в package-lock.json.
Конфликты в package.json обычно легко разрешаются (если они вообще есть), поэтому я думаю, что заманчиво просто удалить package-lock.json и запустить npm install .
В конце концов, это даст вам совершенно новую блокировку пакетов.4.2.1 как версия,
и вы увидите, что вы можете получить что угодно от 4.2.1 до 4.17.20 (последняя версия)

Вот здесь-то и вступает в игру package-lock.json. После установки он «заблокирует» вас на той версии, которую вы только что установили.
Таким образом, если 4.2.1 является последней версией на момент вашей установки, эта версия будет записана в package-lock и с этого момента всегда будет устанавливаться.
Даже если выйдут более новые версии, теоретически совместимые с ним.

Это важно, поскольку гарантирует, что у каждого разработчика в команде будет одна и та же версия на своей машине, и это одинаково важно для CI / CD.
Я бы не хотел выпускать в производство более новую версию , чем мы тестировали, даже если это всего лишь патч.

Итак, когда вы удаляете package-lock.json, вся эта согласованность исчезает.
Каждый node_module, от которого вы зависите, будет обновлен до последней версии, с которой он теоретически совместим.
Это означает без серьезных изменений, кроме мелочей и патчей.Я считаю, что это плохо по трем причинам:

Он полагает, что все строго придерживаются семантического управления версиями, и я искренне сомневаюсь, что это так. Также нет возможности добиться этого.
Основная нулевая версия освобождена от правил семантического управления версиями. Из спецификации semver:
Основная нулевая версия (0.y.z) предназначена для начальной разработки. Все может измениться в любое время. Публичный API НЕ СЛЕДУЕТ считать стабильным.

Взгляните на свой пакетный замок.), используемые вами библиотеки — нет.

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

Будет ли ваше приложение в порядке? Может быть, а может и нет. Никто не может сказать.
Для меня это обычно означает: «регрессионная проверка всего», что, конечно, не то, что я имею в виду, когда просто решаю конфликт.

Что вы можете сделать вместо этого

Мой обычный подход был следующим:

Разрешить конфликты в пакете.json
Возьмите package-lock.json из базовой ветки
снова запустите npm install

Это просто переустановит все изменения, которые мы внесли в нашу ветку.
Однако недавно я узнал о более простом способе:

npm может автоматически обнаруживать конфликты в package-lock.json и разрешать их за нас.
Из документации npm:

Иногда две отдельные установки npm создают блокировки пакетов, которые вызывают конфликты слияния в системах управления версиями. По состоянию на npm @ 5.