Детали, которые игнорируются в управлении зависимостями npm

Это 66-я оригинальная статья без воды.Если вы хотите получить больше оригинальных статей, выполните поиск в официальном аккаунте и подпишитесь на нас~ Эта статья была впервые опубликована в блоге Zhengcaiyun:Детали, которые игнорируются в управлении зависимостями npm

предисловие

Когда дело доходит до npm, первое, что приходит на ум, это установка npm, но видели ли вы node_modules, сгенерированные после установки npm? Знаете ли вы роль файла package-lock.json? Что делают другие зависимости помимо зависимостей и devDependencies? Далее в этой статье мы поделимся с вами некоторыми сведениями о деталях npm, которые вы, возможно, упустили из виду.

механизм установки npm

A и B одновременно зависят от C, где будет установлен пакет C? В чем разница между установкой одной и той же версии C и разных версий? Имеет ли значение порядок пакетов в package.json при установке? Возможно, вы не обращали внимания на эти вопросы в обычное время, поэтому давайте сегодня вместе их изучим.

A и B одновременно зависят от C, где будет установлен этот пакет?

Если есть два пакета A и B, оба из которых зависят от пакета C, npm 2 рекурсивно установит пакеты A и B и зависимые от них пакеты в node_modules. После выполнения увидим./node_modulesЭтот каталог содержит только эти два подкаталога:

node_modules/ 
├─┬ A 
│ ├── C 
├─┬ B 
│ └── C 

Если для установки используется npm 3,./node_modulesКаталог ниже будет содержать три подкаталога:

node_modules/ 
├─┬ A 
├─┬ B 
├─┬ C 

Почему такая разница? Это начинается с того, как работает npm:

Различия в механизмах установки модуля npm 2 и npm 3

Хотя последней версией npm является npm 6, выравнивание каталогов реализовано при изменении версии с npm 2 на npm 3, что сильно отличается от других версий. Итак, давайте подробно рассмотрим различия между двумя версиями.

npm 2 использует простой рекурсивный метод установки при установке зависимостей. воплощать в жизньnpm installПосле этого npm определяет зависимости первого уровня в соответствии с пакетами, указанными в атрибутах dependencies и devDependencies.npm 2 будет рекурсивно устанавливать каждый пакет в node_modules подзависимостей в соответствии с подзависимостями зависимостей первого уровня, пока подзависимости не перестанут зависеть от других модулей. После выполнения увидим./node_modulesЭтот каталог содержит все зависимости в нашем файле package.json, а подзависимости этих зависимостей устанавливаются в свои собственные node_modules, образуя дерево зависимостей, подобное следующему:

Такой каталог имеет очевидные преимущества:

​ 1) Иерархическая структура очень очевидна, вы можете четко видеть подкаталоги всех пакетов, которые мы установили в node_modules первого слоя;

2) Когда вы знаете имя и номер версии нужного вам пакета, вы можете скопировать и вставить соответствующий файл в node_modules, а затем вручную изменить конфигурацию в package.json;

3) Если вы хотите удалить пакет, просто удалите соответствующую строку в файле package.json, а затем удалите каталог пакета в node_modules;

Однако такая иерархическая структура также имеет очевидные дефекты. Когда у меня такая же зависимость d в трех пакетах A, B, и C, выполняетсяnpm installПосле этого D будет загружаться три раза подряд, и по мере того, как наш проект будет становиться все более и более сложным, дерево зависимостей в node_modules будет становиться все более и более сложным, и таких пакетов, как D, будет все больше и больше, что приведет к большому количеству избыточности. ; В системе Windows путь к файлу может быть даже слишком длинным из-за слишком глубокого уровня каталога, вызывающего ошибку, что путь к файлу не может превышать 280 символов;

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

Как npm 3 обрабатывает разные версии одной и той же зависимости?

npm 3 будет проходить по всем узлам и размещать модули на первом уровне node_modules один за другим. При обнаружении повторяющихся модулей они будут отбрасываться. Если будет обнаружена какая-либо несовместимость версий зависимостей, будет продолжать использоваться метод обработки npm 2. Первый помещается в каталог node_modules, а второй — в дерево зависимостей. Например: A, B зависит от D(v 0.0.1), C зависит от D(v 0.0.2):

Но npm 3 принесет новую проблему: из-за выполненияnpm install, согласно сpackage.jsonПорядок зависимостей анализируется по очереди.На приведенном выше рисунке, если порядок C находится перед A и B, дерево node_modules изменится, и произойдет следующая ситуация:

Видно, что npm 3 не решает полностью проблему избыточности, а даже приносит новые проблемы.

Почему появляется package-lock.json?

Почему существует файл package-lock.json? Начнем с файла package.json.

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

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

1) Для некоторых зависимостей могли быть выпущены новые версии с момента их последней установки. Например: когда пакет A устанавливается первым человеком в команде, это версия 1.0.5, а элементы конфигурации в package.jsonA: '^1.0.5'; Когда второй человек в команде снял код, версия пакета А была обновлена ​​до 1.0.8. Согласно спецификации версии semver-range в package.json, версия А после установки npm вторым человеком 1.0..8, могут возникать ошибки, вызванные разными версиями зависимостей;

2) Для проблемы в 1), некоторые друзья могут подумать, исправьте номер версии A какA: '1.0.5'Вы не можете сделать это? Однако такой подход не решил проблему.Например, некоторая зависимость A была версии 2.1.3, когда первый человек скачал ее, но второй человек скачал ее и обновил до версии 2.2.5. time Деревья все равно не совсем одинаковые, исправленная версия - это только версия от себя, а зависимая версия не может быть исправлена.

Решение для недостаточного package.json

Чтобы решить вышеуказанные проблемы и проблемы npm 3, после npm 5.0 файл package-lock.json будет автоматически создан после установки npm.Если в пакете есть файл package-lock.json, при установке npm выполняется, если пакет.Если json совместим с версией в package-lock.json, он будет загружен в соответствии с версией в package-lock.json, если не совместим, будет версия в package-lock.json обновляться в соответствии с версией package.json, и пакет гарантированно - Версия в lock.json совместима с package.json.

Структура файла package-lock.json

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

• version: версия пакета, т. е. этот пакет в настоящее время установлен вnode_modulesверсия в
• resolved: Источник установки для конкретного пакета.
• integrity:Мешокhashзначение, чтобы убедиться, что установленный пакет не был изменен или стал недействительным
• requires: Соответствует зависимым зависимостям и зависимым зависимостямpackage.jsonсерединаdependenciesЗависимости те же
• dependencies: структурный и внешнийdependenciesСтруктура та же, магазин устанавливается в подзависимостиnode_modulesзависимости в

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

Роль файла package-lock.json

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

Отличия и сценарии использования

В настоящее время npm поддерживает следующие типы управления пакетами зависимостей:

• dependencies
• devDependencies
• необязательные зависимости
• peerDependencies одноранговые зависимости
• bundledDependencies связанные зависимости

Давайте посмотрим на различия между этими зависимостями и соответствующими сценариями их применения:

dependencies

зависимости — это зависимости, которые должны использоваться как в среде разработки, так и в производственной среде.Они являются нашими наиболее часто используемыми объектами управления пакетами зависимостей, такими как React, Loadsh, Axios и т. д.npm install XXXЗагруженные пакеты по умолчанию устанавливаются в объект зависимостей, или вы можете использоватьnpm install XXX --saveСкачать пакеты в зависимостях;

devDependencies

devDependencies относится к зависимостям, которые можно использовать в среде разработки, например eslint, debug и т. д., посредствомnpm install packageName --save-devЗагруженные пакеты будут находиться в объекте devDependencies;

Самая большая разница между зависимостями и devDependencies заключается в том, что при запуске пакета выполнениеnpm installВсе зависимости будут установлены по умолчанию, но если вы используетеnpm install --productionЕсли это проект службы узла, его можно использовать для установки и упаковки среды выполнения службы таким образом, чтобы уменьшить размер пакета.

optionalDependencies

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

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

try { 
  var axios = require('axios') 
  var fooVersion = require('axios/package.json').version 
} catch (er) { 
  foo = null 
} 
// .. then later in your program .. 
if (foo) { 
  foo.doFooThings() 
} 

peerDependencies

peerDependencies используется для указания версии пакета, который должен быть установлен на вашем текущем совместимом с плагинами хосте.Что это значит? Например 🌰: наша часто используемая библиотека компонентов реагированияant-design@3.xизpackage.jsonКонфигурация в следующем:

"peerDependencies": { 
  "react": ">=16.9.0", 
  "react-dom": ">=16.9.0" 
 }, 

Предположим, мы создаем проект с именем проект, в котором мы хотим использоватьant-design@3.xЭтот плагин, на данный момент наш проект должен быть установлен первымReact >= 16.9.0а такжеReact-dom >= 16.9.0версия. ​

В npm 2, когда мы загружаемant-design@3.x, зависимости, указанные в peerDependencies, будут следоватьant-design@3.xпринудительно устанавливаются вместе, поэтому нам не нужно указывать зависимости в peerDependencies в файле package.json хост-проекта, но в npm 3 пакеты, указанные в peerDependencies, больше не будут устанавливаться принудительно, а будут получать предупреждения. В настоящее время нам необходимо вручную добавить зависимости в файл package.json;

bundledDependencies

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

{ 
  "name": "project", 
  "version": "1.0.0", 
  "bundleDependencies": [ 
    "axios",  
    "lodash" 
  ] 
} 

При использовании пакета npm для пакета в приведенном выше примере будет сгенерирован файл project-1.0.0.tgz.После использования bundledDependencies две зависимости, Axios и Lodash, будут помещены в пакет вместе, а затем кто-то используетnpm install project-1.0.0.tgzПри загрузке пакета также устанавливаются две зависимости: Axios и Lodash. Следует отметить, что информация о двух пакетах, Axios и Lodash, находится в зависимостях после установки и не включает информацию о версии.

"bundleDependencies": [ 
    "axios", 
    "lodash" 
  ], 
  "dependencies": { 
    "axios": "*", 
    "lodash": "*" 
  }, 

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

Суммировать

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

использованная литература

официальная документация package.json

официальная документация package-lock-json

сводка документации по npm

npm-pack

Рекомендуемое чтение

Руководство по адаптации темного режима

Как разрабатывать кросс-терминальные приложения на основе Electron

Карьера

ZooTeam, молодая, увлеченная и творческая команда, связанная с отделом исследований и разработок продукции Zhengcaiyun, базируется в живописном Ханчжоу. В настоящее время в команде более 50 фронтенд-партнеров, средний возраст которых составляет 27 лет, и почти 30% из них — инженеры с полным стеком, настоящая молодежная штурмовая группа. В состав членов входят «ветераны» солдат из Ali и NetEase, а также первокурсники из Чжэцзянского университета, Университета науки и технологий Китая, Университета Хандянь и других школ. В дополнение к ежедневным деловым связям, команда также проводит технические исследования и фактические боевые действия в области системы материалов, инженерной платформы, строительной платформы, производительности, облачных приложений, анализа и визуализации данных, а также продвигает и внедряет ряд внутренних технологий. Откройте для себя новые горизонты передовых технологических систем.

Если вы хотите измениться, вас забрасывают вещами, и вы надеетесь начать их бросать; если вы хотите измениться, вам сказали, что вам нужно больше идей, но вы не можете сломать игру; если вы хотите изменить , у вас есть возможность добиться этого результата, но вы не нужны; если вы хотите изменить то, чего хотите достичь, вам нужна команда для поддержки, но вам некуда вести людей; если вы хотите изменить установившийся ритм, это будет "5 лет рабочего времени и 3 года стажа работы"; если вы хотите изменить исходный Понимание хорошее, но всегда есть размытие того слоя оконной бумаги.. , Если вы верите в силу веры, верьте, что обычные люди могут достичь необыкновенных вещей, и верьте, что они могут встретить лучшего себя. Если вы хотите участвовать в процессе становления бизнеса и лично способствовать росту фронтенд-команды с глубоким пониманием бизнеса, надежной технической системой, технологиями, создающими ценность, и побочным влиянием, я думаю, что мы должны говорить. В любое время, ожидая, пока вы что-нибудь напишете, отправьте это наZooTeam@cai-inc.com