Package lock json: Page not found · GitHub Pages

Содержание

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 / Блог компании ДомКлик / Хабр

Всем привет! В прошлом посте мы рассмотрели экосистему 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.

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

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

npm, файлы package.json и package-lock.json / Блог компании RUVDS.com / Хабр

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

package.json

package-lock.json

[Советуем почитать] Другие части цикла

Часть 1:

Общие сведения и начало работы

Часть 2:

JavaScript, V8, некоторые приёмы разработки

Часть 3:

Хостинг, REPL, работа с консолью, модули

Часть 4:

npm, файлы package.json и package-lock.json

Часть 5:

npm и npx

Часть 6:

цикл событий, стек вызовов, таймеры

Часть 7:

асинхронное программирование

Часть 8:

Руководство по Node.js, часть 8: протоколы HTTP и WebSocket

Часть 9:

Руководство по Node.js, часть 9: работа с файловой системой

Часть 10:

Руководство по Node.js, часть 10: стандартные модули, потоки, базы данных, NODE_ENV
Полная PDF-версия руководства по Node.js

Основы npm

Npm (node package manager) — это менеджер пакетов Node.js. В первой части этого материала мы уже упоминали о том, что сейчас в npm имеется более полумиллиона пакетов, что делает его самым большим в мире репозиторием кода, написанного на одном языке. Это позволяет говорить о том, что в npm можно найти пакеты, предназначенные для решения практически любых задач.

Изначально npm создавался как система управления пакетами для Node.js, но в наши дни он используется и при разработке фронтенд-проектов на JavaScript. Для взаимодействия с реестром npm используется одноимённая команда, которая даёт разработчику огромное количество возможностей.

▍Загрузка пакетов

С помощью команды

npm

можно загружать пакеты из реестра. Ниже мы рассмотрим примеры её использования.

▍Установка всех зависимостей проекта

Если в проекте имеется файл

package.json

, то установить все зависимости этого проекта можно такой командой:

npm install

Эта команда загрузит всё, что нужно проекту, и поместит эти материалы в папку

node_modules

, создав её в том случае, если она не существует в директории проекта.

▍Установка отдельного пакета

Отдельный можно установить следующей командой:

npm install <package-name>

Часто можно видеть, как эту команду используют не в таком вот простом виде, а с некоторыми флагами. Рассмотрим их:

Флаг --save позволяет установить пакет и добавить запись о нём в раздел dependencies файла package.json, который описывает зависимости проекта. Эти зависимости используются проектом для реализации его основного функционала, они устанавливаются в ходе его развёртывания на сервере (после выхода npm 5 записи об устанавливаемых пакетах в разделе зависимостей делаются автоматически, и без использования этого флага).

Флаг --save-dev позволяет установить пакет и добавить запись о нём в раздел, содержащий перечень зависимостей разработки (то есть — пакетов, которые нужны в ходе разработки проекта, вроде библиотек для тестирования, но не требуются для его работы) файла package.json, который называется devDependencies.

▍Обновление пакетов

Для обновления пакетов служит следующая команда:

npm update

Получив эту команду, npm проверит все пакеты на наличие их новых версий, и, если найдёт их новые версии, соответствующие ограничениям на версии пакетов, заданным в

package.json

, установит их.

Обновить можно и отдельный пакет:

npm update <package-name>

▍Загрузка пакетов определённых версий

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

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

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

▍Запуск скриптов

Файл

package.json

поддерживает возможность описания команд (скриптов), запускать которые можно с помощью такой конструкции:

npm <task-name>

Например, вот как выглядят перечень скриптов, имеющийся в соответствующем разделе файла:

{
  "scripts": {
    "start-dev": "node lib/server-development",
    "start": "node lib/server-production"
  }
}

Весьма распространено использование этой возможности для запуска Webpack:

{
  "scripts": {
    "watch": "webpack --watch --progress --colors --config webpack.conf.js",
    "dev": "webpack --progress --colors --config webpack.conf.js",
    "prod": "NODE_ENV=production webpack -p --config webpack.conf.js",
  }
}

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

$ npm watch
$ npm dev
$ npm prod

▍Куда npm устанавливает пакеты?

При установке пакетов с использованием npm (или

yarn

) доступны два варианта установки: локальная и глобальная.

По умолчанию, когда для установки пакета используют команду наподобие npm install lodash, пакет оказывается в папке node_modules, расположенной в папке проекта. Кроме того, если была выполнена вышеописанная команда, npm также добавит запись о библиотеке lodash в раздел dependencies файла package.json, который имеется в текущей директории.

Глобальная установка пакетов выполняется с использованием флага -g:

npm install -g lodash

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

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

npm root -g

В macOS или Linux файлы пакетов могут оказаться в директории

/usr/local/lib/node_modules

. В Windows это может быть нечто вроде

C:\Users\YOU\AppData\Roaming\npm\node_modules

Однако если вы используете для управления версиями Node.js nvm, путь к папке с глобальными пакетами может измениться.

Я, например, использую nvm, и вышеописанная команда сообщает мне о том, что глобальные пакеты устанавливаются по такому адресу: /Users/flavio/.nvm/versions/node/v8.9.0/lib/node_modules.

▍Использование и выполнение пакетов, установленных с помощью npm

Как использовать модули, установленные с помощью npm, локально или глобально, попадающие в папки

node_modules

? Предположим, вы установили популярную библиотеку

lodash

, содержащую множество вспомогательных функций, используемых в JavaScript-разработке:

npm install lodash

Такая команда установит библиотеку в локальную папку проекта

node_modules

Для того чтобы использовать её в своём коде, достаточно импортировать её с применением команды require:

const _ = require('lodash')

Как быть, если пакет представляет собой исполняемый файл?

В таком случае исполняемый файл попадёт в папку node_modules/.bin/ folder.

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

Итак, после установки пакета с использованием команды npm install cowsay, он, вместе со своими зависимостями, попадёт в node_modules. А в скрытую папку .bin будут записаны символические ссылки на бинарные файлы cowsay.

Как их выполнять?

Конечно, можно, для вызова программы, ввести в терминале нечто вроде ./node_modules/.bin/cowsay, это рабочий подход, но гораздо лучше воспользоваться npx, средством для запуска исполняемых файлов npm-пакетов, включаемым в npm начиная с версии 5.2. А именно, в нашем случае понадобится такая команда:

npx cowsay

Путь к пакету npx найдёт автоматически.

Файл package.json

Файл

package.json

является важнейшим элементов множества проектов, основанных на экосистеме Node.js. Если вы программировали на JavaScript, была ли это серверная или клиентская разработка, то вы, наверняка, уже встречались с этим файлом. Зачем он нужен? Что вам следует о нём знать и какие возможности он вам даёт?

Package.json представляет собой нечто вроде файла-манифеста для проекта. Он даёт в распоряжение разработчика множество разноплановых возможностей. Например, он представляет собой центральный репозиторий настроек для инструментальных средств, используемых в проекте. Кроме того, он является тем местом, куда npm и yarn записывают сведения об именах и версиях установленных пакетов.

▍Структура файла

Вот пример простейшего файла

package.json

{
}

Как видите, он пуст. Нет жёстких требований, касающихся того, что должно присутствовать в подобном файле для некоего приложения. Единственное требование к структуре файла заключается в том, что она должна следовать правилам формата JSON. В противном случае этот файл не сможет быть прочитан программами, которые попытаются получить доступ к его содержимому.

Если вы создаёте Node.js-пакет, который собираетесь распространять через npm, то всё радикальным образом меняется, и в вашем package.json должен быть набор свойств, которые помогут другим людям пользоваться пакетом. Подробнее мы поговорим об этом позже.

Вот ещё один пример package.json:

{
  "name": "test-project"
}

В нём задано свойство

name

, значением которого является имя приложения или пакета, материалы которого содержатся в той же папке, где находится этот файл.4.1.0″
},
«engines»: {
   «node»: «>= 6.0.0»,
   «npm»: «>= 3.0.0»
},
«browserslist»: [
   «> 1%»,
   «last 2 versions»,
   «not ie <= 8»
]
}

Как видите, тут прямо-таки немеряно всего интересного. А именно, здесь можно выделить следующие свойства:

name — задаёт имя приложения (пакета).

version — содержит сведения о текущей версии приложения.

description — краткое описание приложения.

main — задаёт точку входа в приложение.

private — если данное свойство установлено в true, это позволяет предотвратить случайную публикацию пакета в npm.

scripts — задаёт набор Node.js-скриптов, которые можно запускать.

dependencies — содержит список npm-пакетов, от которых зависит приложение.

devDependencies — содержит список npm-пакетов, используемых при разработке проекта, но не при его реальной работе.

engines — задаёт список версий Node.js, на которых работает приложение.

browserlist — используется для хранения списка браузеров (и их версий), которые должно поддерживать приложение.

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

▍Свойства, используемые в package.json

Поговорим о свойствах, которые можно использовать в

package.json

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

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

Свойство name

Свойство

name

задаёт имя пакета:

"name": "test-project"

Имя должно быть короче 214 символов, не должно включать в себя пробелы, должно состоять только из прописных букв, дефисов (

-

) и символов подчёркивания (

_

Подобные ограничения существуют из-за того, что когда пакет публикуется в npm, его имя используется для формирования URL страницы пакета.

Если вы публиковали код пакета на GitHub, в общем доступе, то хорошим вариантом имени пакета является имя соответствующего GitHub-репозитория.

Свойство author

Свойство

author

содержит сведения об авторе пакета:

{
  "author": "Flavio Copes <[email protected]> (https://flaviocopes.com)"
}

Оно может быть представлено и в таком формате:

{
  "author": {
    "name": "Flavio Copes",
    "email": "[email protected]",
    "url": "https://flaviocopes.com"
  }
}

Свойство contributors

Свойство

contributors

содержит массив со сведениями о людях, внёсших вклад в проект:

{
  "contributors": [
    "Flavio Copes <[email protected]> (https://flaviocopes.com)"
  ]
}

Это свойство может выглядеть и так:

{
  "contributors": [
    {
      "name": "Flavio Copes",
      "email": "[email protected]",
      "url": "https://flaviocopes.com"
    }
  ]
}

Свойство bugs

В свойстве

bugs

содержится ссылка на баг-трекер проекта, весьма вероятно то, что такая ссылка будет вести на страницу системы отслеживания ошибок GitHub:

{
  "bugs": "https://github.com/flaviocopes/package/issues"
}

Свойство homepage

Свойство

homepage

позволяет задать домашнюю страницу пакета:

{
  "homepage": "https://flaviocopes.com/package"
}

Свойство version

Свойство

version

содержит сведения о текущей версии пакета:

"version": "1.0.0"

При формировании значения этого свойства нужно следовать правилам

семантического версионирования

. Это означает, в частности, что номер версии всегда представлен тремя цифрами: x.x.x.

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

Изменение этих чисел несёт в себе определённый смысл. Так, релиз пакета, в котором лишь исправляются ошибки, приводит к увеличению значения патч-версии. Если выходит релиз пакета, изменения, внесённые в который, отличаются обратной совместимостью с предыдущим релизом — то меняется минорная версия. В мажорных версиях пакетов могут присутствовать изменения, которые делают эти пакеты несовместимыми с пакетами предыдущих мажорных версий.

Свойство license

Свойство

license

содержит сведения о лицензии пакета:

"license": "MIT"

Свойство keywords

Свойство

keywords

содержит массив ключевых слов, имеющих отношение к функционалу пакета:

"keywords": [
  "email",
  "machine learning",
  "ai"
]

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

Свойство description

Свойство

description

содержит краткое описание пакета:

"description": "A package to work with strings"

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

Свойство repository

Свойство

repository

указывает на то, где находится репозиторий пакета:

"repository": "github:flaviocopes/testing",

Обратите внимание, что у значения этого свойства имеется префикс

github

. Npm поддерживает префиксы и для некоторых других популярных сервисов подобного рода:

"repository": "gitlab:flaviocopes/testing",
"repository": "bitbucket:flaviocopes/testing",

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

"repository": {
  "type": "git",
  "url": "https://github.com/flaviocopes/testing.git"
}

Один и тот же пакет может использовать разные системы контроля версий:

"repository": {
  "type": "svn",
  "url": "..."
}

Свойство main

Свойство

main

задаёт точку входа в пакет:

"main": "src/main.js"

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

Свойство private

Свойство

private

, установленное в

true

, позволяет предотвратить случайную публикацию пакета в npm:

"private": true

Свойство scripts

Свойство

scripts

задаёт список скриптов или утилит, которые можно запускать средствами npm:

"scripts": {
  "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
  "start": "npm run dev",
  "unit": "jest --config test/unit/jest.0.13.0"
}

Свойство browserlist

Свойство

browserlist

позволяет сообщить о том, какие браузеры (и их версии) собирается поддерживать разработчик пакета:

"browserslist": [
  "> 1%",
  "last 2 versions",
  "not ie <= 8"
]

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

Показанное здесь в качестве примера значение свойства browserlist означает, что вы хотите поддерживать как минимум 2 мажорные версии всех браузеров с как минимум 1% использования (эти данные берутся с ресурса CanIUse.com), за исключением IE 8 и более старых версий этого браузера (подробнее об этом можно узнать на странице пакета browserlists).

▍Хранение в package.json настроек для различных программных инструментов

package.json

можно хранить настройки для различных вспомогательных инструментов вроде Babel или ESLint.0.13.0, это означает, что вам подходят новые патч-версии и минорные версии пакета. То есть, вас устроят версии пакета 0.13.1, 0.14.0, и так далее.

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

>: подходят любые версии пакета, которые больше заданной.

>=: подходят любые версии пакета, которые равны или больше заданной.

<=: вас устроят пакеты, версии которых равны заданной или меньше её.

<: вас интересуют пакеты, версии которых меньше заданной.

=: вам нужна только заданная версия пакета.

-: используется для указания диапазона подходящих версий, например — 2.1.0 - 2.6.2.

||: позволяет комбинировать наборы условий, касающихся пакетов. Например это может выглядеть как < 2.1 || > 2.6.

Есть и ещё некоторые правила:

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

latest: указывает на то, что вам требуется самая свежая версия некоего пакета.

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

1.0.0 || >=1.1.0 <1.2.0

указывает на то, что планируется использовать либо версию пакета

1.0.0

, либо версию, номер которой больше или равен

1.1.0

, но меньше

1.2.0

Файл package-lock.json

Файл

package-lock.json

используется с момента появления npm версии 5. Он создаётся автоматически при установке Node.js-пакетов. Что это за файл? Возможно, вы не знакомы с ним даже если знали о

package.json

, который существует гораздо дольше него.

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

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

В Git не коммитят папку node_modules, так как обычно она имеет огромные размеры. Когда вы пытаетесь воссоздать проект на другом компьютере, то использование команды npm install приведёт к тому, что, если, при использовании спецификатора ~ в применении к версии некоего пакета, вышел его патч-релиз, установлен будет не тот пакет, который использовался при разработке, а именно этот патч-релиз.. Если же при указании версии пакета спецификаторы не использовались, то будет установлена именно его указанная версия и проблема, о которой идёт речь, окажется в такой ситуации неактуальной.

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

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

Эта концепция не нова, менеджеры пакетов, применяемые в других языках программирования (вроде менеджера Composer в PHP) используют похожую систему многие годы.

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

Версии зависимостей будут обновлены в package-lock.json после выполнения команды npm update.

▍Пример файла package-lock.json

В этом примере продемонстрирована структура файла

package-lock.json

, который входит в состав пакет cowsay, устанавливаемого в пустой папке командой npm

install cowsay

{
  "requires": true,
  "lockfileVersion": 1,
  "dependencies": {
    "ansi-regex": {
      "version": "3.0.0",
      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-3.
0.0.tgz",
      "integrity": "sha1-7QMXwyIGT3lGbAKWa922Bas32Zg="
    },
    "cowsay": {
      "version": "1.3.1",
      "resolved": "https://registry.npmjs.org/cowsay/-/cowsay-1.1.0.0"
      }
    },
    "get-stdin": {
      "version": "5.0.1",
      "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-5.0.
1.tgz",
      "integrity": "sha1-Ei4WFZHiH/TFJTAwVpPyDmOTo5g="
    },
    "is-fullwidth-code-point": {
      "version": "2.0.0",
      "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/
is-fullwidth-code-point-2.0.0.tgz",
      "integrity": "sha1-o7MKXE8ZkYMWeqq5O+764937ZU8="
    },
    "minimist": {
      "version": "0.0.10",
      "resolved": "https://registry.npmjs.org/minimist/-/minimist-0.0.10
.tgz",
      "integrity": "sha1-3j+YVD2/lggr5IrRoMfNqDYwHc8="
    },
    "optimist": {
      "version": "0.6.1",
      "resolved": "https://registry.npmjs.org/optimist/-/optimist-0.6.1.tgz",
      "integrity": "sha1-2j6nRob6IaGaERwybpDrFaAZZoY=",
      "requires": {
        "minimist": "~0.0.1",
        "wordwrap": "~0.0.2"
      }
    },
    "string-width": {
      "version": "2.1.1",
      "resolved": "https://registry.npmjs.org/string-width/-/string-width-2.3.0.0"
      }
    },
    "strip-eof": {
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/strip-eof/-/strip-eof-1.0.0.tgz",
      "integrity": "sha1-u0P/VZim6wXYm1n80SnJgzE2Br8="
    },
    "wordwrap": {
      "version": "0.0.3",
      "resolved": "https://registry.npmjs.org/wordwrap/-/wordwrap-0.0.3.tgz",
      "integrity": "sha1-o9XabNXAvAAI03I0u68b7WMFkQc="
    }
  }
}

Разберём этот файл. Мы устанавливаем пакет cowsay, который зависит от следующих пакетов:

get-stdin

optimist

string-width

strip-eof

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

requires

, которые имеются у некоторых из них:

ansi-regex

is-fullwidth-code-point

minimist

wordwrap

strip-eof

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

version

, есть поле

resolved

, указывающее на расположение пакета, и строковое свойство

integrity

, которое можно использовать для проверки целостности пакета.

Итоги

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

package.json

package-lock.json

. В следующий раз продолжим разбирать возможности npm и коснёмся использования npx.

Уважаемые читатели! Какой менеджер пакетов вы предпочитаете — npm или yarn?

Удаление `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.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…

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

После обновления моего NPM до последней версии (с 3.X до 5.2.0) и запуска npm install в существующем проекте я получаю автоматически созданный файл package-lock.json .

Я могу сказать, что package-lock.json дает мне точное дерево зависимостей, а не package.json .

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

Необходимы ли они оба для работы NPM?

Безопасно ли или возможно использовать только файл package-lock.json ?

В документах по пакету-lock.json (doc1 , doc2 ) об этом ничего не говорится.

Редактировать :

Еще немного поразмыслив, я пришел к выводу, что если кто-то захочет использовать ваш проект с более старой версией NPM (до 5.x), он все равно установит все зависимости, но с менее точными версиями (патч-версиями)

npm

npm-install

package.json

package-lock.json

Поделиться

Источник

Omri Luzon

12 июля 2017 в 08:35

4 ответа

NPM5, в чем разница пакета-lock.json с package.json?
После обновления NPM до версии 5 я нашел файл package-lock.json с package.json. В чем разница между этими двумя файлами? В чем преимущества package-lock.json ?
Когда именно используется пакет-lock.json?
Я знаю, что основной смысл наличия файлов .lock заключается в том, что они содержат определенные версии пакетов (в то время как package.json может указывать диапазоны), так что при установке одного и того же проекта на разные машины вы можете гарантировать одни и те же версии пакетов. Что Я Хочу…

148

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

Вам нужен package.json ? Да.

Можете ли вы создать проект только с package-lock.json ? Нет.

package.json используется не только для зависимостей — например, для определения свойств проекта, описания, информации о лицензии author &, сценариев и т. Д. package-lock.json используется исключительно для блокировки зависимостей с определенным номером версии.

Поделиться

Markus Stefanko

02 декабря 2018 в 08:32

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

package.json: записывает минимальную версию, необходимую вашему приложению. Если вы обновите версии определенного пакета, это изменение не будет отражено здесь.

Поделиться

Narendar Reddy M

20 июня 2019 в 09:42

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

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

Поделиться

Stanley Kirdey

23 июля 2017 в 05:56

Потребность в обоих файлах package.json, package-lock.json в приложении angular
Я новичок в angular. Когда я получил образец приложения angular, установленного с помощью angular-cli, я увидел определенные файлы package.json и package-lock.json. Среди этих файлов package-lock.json files имеет точные зависимости, определенные и package.json имеет другие важные факты, такие как…
Управление package.json & package-lock.json с помощью Git
Я знаю, что вы должны добавить пакет-lock.json к своему git repo, чтобы убедиться, что члены команды используют одни и те же версии зависимостей. Запуск npm install проверит наличие пакета-lock.json и установит указанные там версии. Если файл блокировки отсутствует, он установит пакеты из их…

Более точное и подробное объяснение причины хранения пакета-lock.json можно найти здесь

Поделиться

Vivek Goel

13 мая 2020 в 14:09

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 — Русский — 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

Файл package-lock.json

В версии 5 npm представил файл package-lock.json .

Что это? Вы, вероятно, знаете о файле package.json , который встречается гораздо чаще и существует гораздо дольше.

Цель файла package-lock.json — отслеживать точную версию каждого установленного пакета, чтобы продукт был на 100% воспроизводимым таким же образом, даже если пакеты обновляются сопровождающими.1.13.0 , вы получите патч и второстепенные выпуски: 1.13.1 , 1.14.0 и так далее до 2.0.0 .

, если вы напишете 0.13.0 , это точная версия, которая будет использоваться, всегда

Вы не фиксируете Git свою папку node_modules, которая обычно огромна, и когда вы пытаетесь реплицировать проект на другой компьютер с помощью команды npm install , если вы указали синтаксис ~ и выпущен патч-релиз пакета, он будет установлен. и второстепенные выпуски.

Если вы укажете точные версии, например 0.13.0 в примере, эта проблема не затронет вас.

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

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

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

Эта концепция не нова, и менеджеры пакетов других языков программирования (например, Composer в PHP) используют аналогичную систему в течение многих лет.

Файл package-lock.json должен быть зафиксирован в вашем репозитории Git, чтобы его могли получить другие люди, если проект является общедоступным или у вас есть соавторы, или если вы используете Git в качестве источника для развертываний. 5.1.0.0 «

}

» get-stdin «: {

» version «:» 5.0.1 «,

» resolved «:» https:

1.tgz «,

«целостность»: «sha1-Ei4WFZHiH / TFJTAwVpPyDmOTo5g =»

«is-fullwidth-code-point»: {

«версия»: «2.0.0»,

«разрешено»: «https:

is-fullwidth-code-point-2.0.0.tgz «,

» целостность «:» sha1-o7MKXE8ZkYMWeqq5O + 764937ZU8 = «

» minimist «: {

» версия «:» 0 .0.10 «,

» разрешено «:» https:

.tgz «,

» целостность «:» sha1-3j + YVD2 / lggr5IrRoMfNqDYwHc8 = «

» optimist «: {

» версия «

: «0.6.1»,

«разрешено»: «https://registry.npmjs.org/optimist/-/optimist-0.6.1.tgz»,

«целостность»: «sha1-2j6nRob6IaGaERwybpDrFaAZZoY =»,

«требует»: {

«минимист»: «~ 0.0.1»,

«перенос слов»: «~ 0.0.2»

}

«ширина строки»: {

«версия»: «2.3.0.0 «

}

» strip-eof «: {

» версия «:» 1.0.0 «,

» разрешено «:» https://registry.npmjs.org/strip -eof / — / strip-eof-1.0.0.tgz «,

» целостность «:» sha1-u0P / VZim6wXYm1n80SnJgzE2Br8 = «

» wordwrap «: {

» версия «:» 0.0. 3 «,

» разрешено «:» https://registry.npmjs.org/wordwrap/-/wordwrap-0.0.3.tgz «,

» целостность «:» sha1-o9XabNXAvAAI03I0u68b7WMFkQc = «

}

Мы установили cowsay , который зависит от

get-stdin
optimist
ширина струны
strip-eof

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

ansi-regex
is-fullwidth-code-point
minimist
wordwrap
strip-eof

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

`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 никаких претензий не возникает, если я снимаю блокировку пакета.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 | Блог TkDodo`

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

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

Одна вещь, которая может стоить дорого, если сделана неправильно, - это разрешение конфликтов в сгенерированных файлах, таких как package-lock.json. Обычно это происходит, когда две ветки добавляют или обновляют зависимость. версия,
что означает «совместимая с версией, согласно семверу».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.7.0, эти конфликты можно разрешить, вручную исправив все конфликты package.json, а затем снова запустив npm install [—package-lock-only]. npm автоматически разрешит любые конфликты за вас и напишет объединенную блокировку пакета, которая включает в себя все зависимости из обеих ветвей в разумном дереве. Если указан —package-lock-only, он сделает это без изменения вашего локального node_modules /.

Это означает, что мы можем просто сохранить конфликты в файле блокировки.
Все, что нам нужно сделать, это получить посылку.json, а все остальное npm сделает за нас 🎉.

Хотел бы я знать об этом раньше — это избавило бы меня от некоторых проблем.

Согласен? Не согласны? Дайте мне знать в комментариях ниже ⬇️

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

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

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

package-lock.json — это файл, созданный npm (начиная с версии 5 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 или любую другую команду, изменяющую зависимости,
пакет-замок .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

Опубликовано 4 июня 2018 г. автором

Арам Древекенин

Некоторое время экосистема JavaScript является хостом для нескольких различных форматов файлов блокировки зависимостей, включая yarn yarn.lock и npm’s package-lock.json .

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

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

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

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

Как работает под капотом

Раньше yarn import полагался на каталог пакета node_modules для определения фиксированных версий, до которых новый файл yarn.lock должен разрешить свои диапазоны semver. Теперь он возвращается к этому поведению, если не может найти файл package-lock.json .

Когда это происходит, yarn создает дерево зависимостей, используя npm-logic-tree из package.json и package-lock.json в корневом каталоге проекта. Затем он использует фиксированные версии в этом дереве для создания собственного файла блокировки yarn.lock .
В результате yarn. 1.1.0.0 версия "1.0.5"

Здесь b зависимость c изменит свою заблокированную версию с 1.0.1 на 1.0.5 , потому что yarn.lock не может выразить это дублирование. Yarn выбирает и стремится иметь единую разрешенную версию для всех совместимых диапазонов версий. Хотя в большинстве случаев такие незначительные изменения не должны иметь большого эффекта, мы рекомендуем вам использовать эту функцию с осторожностью. Вы все еще можете переопределить диапазоны, если вам нужно, используя функцию выборочного разрешения версий в yarn.

Планы на будущее

В настоящее время мы планируем добавить некоторые предупреждения для пользователей, которые для установки пакетов используют как yarn , так и npm в одном репозитории. При необходимости мы также можем попытаться расширить эту функцию для других форматов файлов блокировки. Если вы хотите указать на другие проблемы совместимости или попробовать свои силы в их решении — мы рекомендуем вам сообщить о проблеме или, лучше, исправить ее, отправив PR.

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

package-lock.json — в GIT или нет?

tl; dr

Поместите в ГИТ
Передавать каждый раз при изменении
Никогда не удаляйте

Что такое блокировка версий и зачем она нам нужна?

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

Но как узнать, что то, что вы тестировали локально, — это тот же код, что и на CI, и тот же код, который развертывается в производственной среде?

Ваш код находится внутри GIT (или другого элемента управления версиями). Если вы вытащите репозиторий в тот же самый коммит, у вас будет тот же код.

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

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

Итак, файл блокировки хранит версии всех наших зависимостей, и всякий раз, когда кто-то запускает npm install , он получит ту же версию вашего приложения, включая внешние зависимости.

Почему бы просто не сохранить точные версии в package.json?

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

Почему бы не удалить package-lock.json?

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

Что вы на самом деле пытаетесь сделать? Если у вас возникла какая-то странная проблема, связанная с npm, просто удалите node_modules и снова запустите npm install . Удаление package-lock.json никогда не является решением.

Зачем использовать package-lock.json?

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

Надеюсь, это поможет понять.И если вы все еще не уверены в объяснении, просто слепо следуйте 3 правилам из раздела tl; dr. Это лучше, чем ничего

Package lock json: Page not found · GitHub Pages

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

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

package-lock.json

npm, файлы package.json и package-lock.json / Блог компании RUVDS.com / Хабр

Основы npm

▍Загрузка пакетов

▍Установка всех зависимостей проекта

▍Установка отдельного пакета

▍Обновление пакетов

▍Загрузка пакетов определённых версий

▍Запуск скриптов

▍Куда npm устанавливает пакеты?

▍Использование и выполнение пакетов, установленных с помощью npm

Файл package.json

▍Структура файла

▍Свойства, используемые в package.json

Свойство name

Свойство author

Свойство contributors

Свойство bugs

Свойство homepage

Свойство version

Свойство license

Свойство keywords

Свойство description

Свойство repository

Свойство main

Свойство private

Свойство scripts

Свойство browserlist

▍Хранение в package.json настроек для различных программных инструментов

Файл package-lock.json

▍Пример файла package-lock.json

Итоги

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

3 ответа

Похожие вопросы:

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

4 ответа

Похожие вопросы:

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

Description

Hidden Lockfiles

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

Формат файла

dependencies

См.также

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

Файл package-lock.json

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

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

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

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

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

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

Трек package-lock.json

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

TL; DR

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

Импорт пряжи теперь использует package-lock.json

Как работает под капотом

Планы на будущее

package-lock.json — в GIT или нет?

tl; dr

Что такое блокировка версий и зачем она нам нужна?

Почему бы просто не сохранить точные версии в package.json?

Почему бы не удалить package-lock.json?

Зачем использовать package-lock.json?

Добавить комментарий Отменить ответ

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

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