Управление зависимостями в nodejs

Node.js

На мой взгляд, причина успеха nodejs заключается не только в том, что он принимает тот же синтаксис, что и интерфейсные js, и напрямую привлекает большое количество разработчиков интерфейсов в качестве первых пользователей, его встроенный менеджер пакетов npm также отличный участник. npm может очень хорошо управлять зависимостями проектов nodejs, а также позволяет разработчикам очень легко публиковать свои собственные пакеты. Таким образом, независимо от того, используете ли вы чужой пакет или публикуете свой собственный пакет для использования другими, стоимость невелика. По сравнению с Java 1.x, которую я изучал в колледже, это намного спокойнее и приятнее (сейчас Java уже не та, что раньше, комментировать не смею), если разработчики будут полны энтузиазма, вся экология будет активнее, и скорость прогресса будет меньше быстрее. Взгляните на долю JS-проектов на GitHub, а затем посмотрите на количество пакетов на официальном сайте npm, вы можете получить представление.

Новичок из компании некоторое время назад задал мне вопрос: как различать зависимости проекта, какие из них должны быть помещены в зависимости, а какие в devDependencies?

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

  • зависимости (обычно используемые)
  • devDependencies (обычно используется)
  • peerDependencies (реже используется)
  • bundledDependencies (раньше я им не пользовался)
  • необязательные зависимости (я не использовал это раньше)

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

dependencies

Это самая основная зависимость npm через командуnpm i xxx -Sилиnpm i xxx --saveустановить пакет и добавить его в зависимости в package.json (здесьiдаinstallсокращение для обоих).

Если вы пишете только имя пакета, установите последнюю версию пакета в текущем реестре npm; если вы хотите указать версию, вы можете написать номер версии после имени пакета, напримерnpm i webpack@3.0.0 --save.

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

зависимостей относительно просто, поэтому я не буду объяснять это больше. Примечание: npm 5.x можно опустить с самого начала.--save, то есть при выполненииnpm install xxx, npm также добавит зависимости пакетов в package.json. Чтобы отключить эту функцию, используйтеnpm config set save false.

devDependencies

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

Первое определение. Как следует из названия, devDependencies — это зависимости, используемые при разработке, которые отличаются от реальных зависимостей. То есть,Зависимости, которые не нужно использовать в онлайн-состоянии, являются зависимостями разработки..

Больше смысла. Почему npm разветвил его отдельно? Конечная цель — уменьшить размер каталога node_modules иnpm installвремя потрачено. Поскольку зависимости npm являются вложенными, может показаться, что в package.json всего несколько зависимостей, но на самом деле он распространяется на N, а N распространяется на N в квадрате, распределяясь слой за слоем, можно сказать, что потомки бесконечный. Если вы сможете свести к минимуму неиспользуемые зависимости, вы сможете сэкономить ресурсы жесткого диска онлайн-компьютеров и сэкономить время на развертывание и подключение к сети.

В реальной разработке, вероятно, есть несколько категорий, которые можно классифицировать как зависимости разработки:

  1. инструменты для сборки

    Наиболее популярными являются webpack и rollup, а в прошлом были grunt, gulp и т. д. Эти инструменты сборки генерируют производственный код, а затем используют сжатый код непосредственно при его использовании в Интернете. Следовательно, такие инструменты сборки зависят от разработки.

    Как и веб-пакет, он также делится на использование кода (webpack) и использование командной строки (webpack-cli), это зависимости разработки. Кроме того, они также могут предоставлять некоторые встроенные общие плагины, такие какxxx-webpack-plugin, они также считаются зависимостями разработки.

  2. препроцессор

    Это относится к инструменту, который выполняет определенную обработку исходного кода для создания окончательного кода. Типичные — less, stylus, sass, scss и т. д. в CSS и coffee-script, babel и т. д. в JS. Хотя они делают вещи по-разному, принцип тот же.

    Возьмем, к примеру, Babel. Есть два наиболее часто используемых способа его использования. Один встроен в инструментальные средства, такие как веб-пакет или накопительный пакет, обычно в виде загрузчика или плагина, например.babel-loader. Второй - использовать в одиночку (более мелкие проекты), такие какbabel-cli. У babel также есть собственная система плагинов, напримерxxx-babel-plugin. Точно так же меньше также имеет соответствующееless-loaderа такжеlessc. Все это считается зависимостями разработки.

    В вавилоне есть еще одно примечание, а именноbabel-runtimeявляются зависимостями вместо devDependencies. Конкретный анализ, о котором я упоминал в предыдущей статье о Babel, повторяться не будет.

  3. инструменты для тестирования

    Строго говоря, тестирование и разработка — это не один процесс. Но они оба относятся к «зависимостям, которые не нужно использовать в онлайн-статусе», поэтому они также классифицируются как зависимости разработки. обычно используется какchai, e2e, karma, coverallsИ так далее.

  4. Это действительно пакет зависимостей только для разработки

    Последняя категория более сложная, и ее сложно охватить одной большой категорией, короче, она нужна для разработки, но по факту она либо уже запакована в конечный код, либо не нуждается в использовании. Напримерwebpack-dev-serverПоддержка горячей загрузки разработки, онлайн не требуется;babel-registerЕго нельзя использовать в сети из соображений производительности. Другие также могут быть связаны с конкретным бизнесом, это зависит от того, как разработчики себя идентифицируют.

Чтобы установить зависимости как зависимости разработки, вы можете использоватьnpm i -Dилиnpm i --save-devЗаказ.

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

peerDependencies

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

Если мы разработаем обычный пакет, например с именемmy-lib. который нужно использоватьrequestЭтот пакет используется для отправки запроса, поэтому код должен иметьconst request = require('request'). Как обсуждалось выше, в этом случаеrequestОн отображается в package.json как зависимости. Затем пользователь передает командуnpm i my-libПри установке нас этоrequestОн также устанавливается как часть зависимостей в проекте пользователя.

Тогда зачем нам эти peerDependencies?

Согласно документации на официальном сайте npm, это свойство в основном используется для проектов плагинов. Традиционно для процветания экосистемы плагинов проекты плагинов обычно разрабатываются как можно более простыми, связанными через структуры данных и фиксированные интерфейсы методов, в то время какНе требует, чтобы проекты плагинов зависели от онтологии. Например, промежуточное ПО Express, с которым мы более знакомы, если вы возвращаете методreturn function someMiddleware(req, res, next), он становится экспресс промежуточным программным обеспечением, которое вызывается онтологией, и передает информацию онтологии через три параметра, которые используются внутри плагина. Поэтому промежуточному ПО Express не нужно полагаться на Express. Подобные случаи также включают плагины Grunt, плагины Chai и транспорты Winston.

Но очевидно,Такие плагины нельзя запускать независимо от онтологии.. Следовательно, хотя подключаемый модуль не зависит от онтологии, для его фактического запуска пользователь также должен включить онтологию в качестве зависимости. Это промежуточное состояние между «независимо» и «зависимо», которое является основным сценарием использования peerDependencies.

Например, мы предоставляем пакет с package.json следующим образом:

{
  "name": "my-greate-express-middleware",
  "version": "1.0.0",
  "peerDependencies": {
    "express": "^3.0.0"
  }
}

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

bundledDependencies

Это менее распространенная зависимость, чем peerDependencies, и ее также можно записать как bundleDependencies (опустите d после пакета). В отличие от приведенных выше зависимостей, это свойство является не объектом пар ключ-значение, а массивом строк, представляющих имя пакета. Например

{
  "name": "awesome-web-framework",
  "version": "1.0.0",
  "bundledDependencies": [
    "renderized", "super-streams"
  ]
}

Когда мы хотим опубликовать проект в сжатом пакете (например, вы не хотите помещать его в реестр npm), мы будем использоватьnpm packдля генерации (как в приведенном выше примере, он будет генерироватьawesome-web-framework-1.0.0.tgz). После написания bundledDependencies npm поместит в него два пакета (renderized, super-streams) также добавляются в сжатый пакет вместе. После этого другие пользователи выполняютnpm install awesome-web-framework-1.0.0.tgzЭти две зависимости также будут установлены.

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

optionalDependencies

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

  1. Даже если установка этой зависимости завершится неудачно, это не повлияет на весь процесс установки.

  2. Программа должна обрабатывать случай, когда установка не удалась сама по себе.

По второму пункту хочу сказать следующее.

let foo
let fooVersion
try {
  foo = require('foo')
  fooVersion = require('foo/package.json').version
} catch (e) {
  // 安装依赖失败时找不到包，需要自己处理
}

// 如果安装的依赖版本不符合实际要求，我们也需要自己处理，当做没安装到
if (!isSupportVersion(fooVersion)) {
  foo = null
}

// 如果安装成功，执行某些操作
if (foo) {
  foo.doSomeThing()
}

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

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

запись номера версии

Для вышеупомянутых пяти зависимостей, за исключением bundledDependencies, для остальных четырех требуется запись номера версии. Если как пользователь, используйтеnpm i --saveилиnpm i --save-devНомер версии зависимостей будет сгенерирован автоматически, но я полагаю, что вы все же немного понимаете часто используемые номера версий.

Прежде всего, мы должны выяснить определение трехзначного номера версии, взяв в качестве примера "a.b.c", их значения таковы:

  1. а - основная версия (также называемая основной версией)

    Обновление основной версии, вероятно, будет означать API или использование, несовместимое с более ранней версией, разрушительное обновление (например, веб-пакет 3 -> 4).

  2. б - минорная версия (также называемая минорной версией)

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

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

  3. в - заплата (заплатка)

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

Затем мы смотрим на обычное написание номера версии:

  1. «1.2.3» — игнорирует точный номер версии обновления.

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

  2. «^1.2.3» — компромисс между обновлениями и безопасностью

    Этоnpm i xxx --saveПосле этого номер версии по умолчанию, сгенерированный системой (^плюс текущий номер последней версии), официальное определение «совместимо с другими изменениями, кроме крайнего левого ненулевого номера версии» (допускает изменения, которые не изменяют крайнюю левую ненулевую цифру в [основном, минор, патч] кортеж). Это предложение очень аппетитно, и вы можете понять его на нескольких примерах:

    1. «^ 1.2.3» эквивалентно «> = 1.2.3

    2. «^0.2.3» эквивалентно «>= 0.2.3

    3. «^0.0.3» эквивалентно «>= 0.0.3

    Как видно из этих примеров,^является обновленной и безопасной совместимой нотацией. Как правило, когда номер основной версии обновлен до 1, это означает, что проект официально выпущен, а начало 0 означает, что он все еще находится в бета-версии.^Причина обращения с ними по-разному.

  3. "~1.2.3" - чем^Более безопасные второстепенные обновления версий

    о~Определение разделено на две части: если указан минорный номер версии (вторая цифра), совместимы только модификации патча (третья цифра); если минорный номер версии не указан, то совместимы модификации второй и третьей цифр. Давайте разберемся с этим определением в двух случаях:

    1. "~1.2.3" перечисляет дополнительный номер версии (2), поэтому он совместим только с модификацией третьего бита, что эквивалентно «>= 1.2.3

    2. «~ 1.2» также указывает дополнительный номер версии, поэтому он совместим с модификацией третьей цифры, как указано выше, что эквивалентно «> = 1.2.0

    3. «~1» не указывает дополнительный номер версии, который совместим со вторым и третьим изменениями, поэтому он эквивалентен «>= 1.0.0

    а также^разница в том,~Не правильно0или1обрабатываются по-разному, поэтому «~ 0» эквивалентно «> = 0.0.0 ~Будьте более осторожны. когда первый0И когда указано второе место, они эквивалентны, например~0.2.3а также^0.2.3.

    В старой версии nodejs (v0.10.26, выпущенная в феврале 2014 г.)npm i --saveПо умолчанию используется~, который теперь был изменен на^. Это изменение также позволяет пользователям обновлять зависимости в максимально возможной степени.

  4. "1.x" или "1.*" - использовать подстановочные знаки

    Это гораздо легче понять, чем два символа выше.x(как в верхнем, так и в нижнем регистре) и*имеют одно и то же значение, оба означают, что все может быть сопоставлено. Конкретно:

    1. "*" или "" (пустая строка) означает, что может быть найдена любая версия.

    2. «1.x», «1.*» и «1» указывают на то, что требуется основная версия.1, что эквивалентно ">=1.0.0

    3. «1.2.x», «1.2.*» и «1.2» означают блокировку первых двух битов, поэтому это эквивалентно «>= 1.2.0

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

  5. «1.2.3-beta.2» — с предварительными ключевыми словами, такими как alpha, beta, rc, pr и т. д.

    Давайте начнем с определения пре-релиза, нам нужно подумать об этом с точки зрения разработчика пакета. Предполагая, что текущая онлайн-версия "1.2.3", если я внесу некоторые изменения, мне нужно будет выпустить версию "1.2.4", но я не хочу запускать ее напрямую (потому что пользователи, использующие "~1.2.3" или `^1.2.3" будет автоматически обновляться напрямую), что требует использования предварительных функций. Поэтому я могу выпустить "1.2.4-alpha.1" или "1.2.4-beta.1" и т. д.

    После понимания первоначального намерения его рождения последующее использование очень естественно.

    1. ">1.2.4-alpha.1" означает, что я принимаю версию "1.2.4"все больше 1альфа предварительная версия. Так что что-то вроде "1.2.4-alpha.7" подходит, но ни "1.2.4-beta.1", ни "1.2.5-alpha.2" не подходят. Кроме того, если это официальная версия (без ключевых слов предварительной версии), если номер версии соответствует требованиям, номер предварительной версии не проверяется, например «1.2.5», «1.3.0». одобрены.

    2. «~ 1.2.4-альфа.1» означает «> = 1,2,4-альфа.1

    3. «^1.2.4-альфа.1» означает «>=1.2.4-альфа.1

Существует больше способов записать номер версии, например диапазон (a - b), больше или меньше (>=a semver, который также является пакетом npm, который можно использовать для сравнения размера двух номеров версий, их соответствия требованиям и т. д.

другое написание

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

Tag

В дополнение к номеру версии обычно пакет также может иметь тег для идентификации некоторых промежуточных версий. Например, выражение express@next означает, что выйдет следующая основная версия (вы можете узнать об этом заранее), а some-lib@latest эквивалентно some-lib, потому что last существует по умолчанию и указывает на последнюю версию. Другие пользовательские теги могут быть переданы разработчикомnpm tagуказать.

потому чтоnpm i package@versionа такжеnpm i package@tagСинтаксис тот же, поэтому номера тегов и версий не должны повторяться.Поэтому обычно рекомендуется, чтобы тег не начинался с цифры или буквы v.

URL

Вы можете указать URL-адрес, чтобы указать исходный адрес зависимого пакета, обычно это пакет tar, например"https://some.site.com/lib.tar.gz". Этот пакет tar обычно доступен черезnpm packчтобы публиковать.

Кстати: по сути, все пакеты npm выпускаются в виде архивов. использоватьnpm publishМаршрутно выпущенный пакет также совершается суффикс Crown NPM, которая разработана реестром NPM для загрузки.

Git URL

Вы можете указать адрес Git (не только GitHub, любой протокол git), и npm автоматически загрузит и установит его с этого адреса. Здесь нужно указать протокол, имя пользователя, пароль, путь, имя ветки и номер версии и т.д., что посложнее. Подробности можно посмотретьофициальная документация, Например:

git+ssh://git@github.com:npm/cli.git#v1.0.27
git+ssh://git@github.com:npm/cli#semver:^5.0
git+https://isaacs@github.com/npm/cli.git
git://github.com/npm/cli.git#v1.0.27

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

{
  "dependencies": {
    "express": "expressjs/express",
    "mocha": "mochajs/mocha#4727d357ea",
    "module": "user/repo#feature\/branch"
  }
}

локальный путь

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

{
  "dependencies": {
    "bar1": "file:../foo/bar1",
    "bar2": "file:~/foo/bar2",
    "bar3": "file:/foo/bar3"
  }
}

package-lock.json

Начиная с npm 5.x, выполнениеnpm iПосле этого в корневом каталоге будет сгенерирован дополнительный package-lock.json. Теперь, когда мы поговорили о зависимостях, позвольте мне рассказать о структуре и функциях этого package-lock.json.

Package-lock.json внутренне записывает фактическую информацию об установке каждой зависимости, такую ​​как имя, номер установленной версии, установленный адрес (адрес пакета tar в реестре npm) и так далее. Кроме того, он также будет записывать зависимости зависимостей, поэтому весь файл представляет собой древовидную структуру, сохраняя отношения вложенности зависимостей (аналогично каталогу node_modules предыдущих версий). Простой пример выглядит следующим образом:

{
  "name": "my-lib",
  "version": "1.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "array-union": {
      "version": "1.0.2",
      "resolved": "http://registry.npm.taobao.org/array-union/download/array-union-1.0.2.tgz",
      "integrity": "sha1-mjRBDk9OPaI96jdb5b5w8kd47Dk=",
      "dev": true,
      "requires": {
        "array-uniq": "^1.0.1"
      }
    }
  }
}

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

Четыре основные причины его существования:

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

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

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

  4. В процессе установки npm внутренне проверяет существующие зависимости в каталоге node_modules и сравнивает их с package-lock.json. Если это повторяется, пропустите установку, что может значительно оптимизировать время установки.

Предложение официального сайта npm: отправьте package-lock.json в кодовую базу вместе, не игнорируйте. но выполнениеnpm publish, оно будет проигнорировано и не опубликовано.

yarn

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

В данном случае Facebook вышел в лидеры, выпустив еще один разработанный ими менеджер пакетов — yarn (версия 1.0 в сентябре 2017 года). Как только появится претендент, это неизбежно приведет к конкуренции между двумя сторонами с точки зрения функциональности, стабильности, простоты использования и других аспектов, что также крайне выгодно для разработчиков. В результате npm также вобрал в себя многие преимущества, позаимствованные у yarn, например, описанный выше package-lock.json, который изначально был производным от yarn.lock. Итак, давайте кратко сравним различия между ними и то, как мы должны выбирать.

yarn

  1. блокировка версии

    Это обсуждалось в package-lock.json и не будет повторяться здесь. На данный момент оба уже доступны.

  2. Управление несколькими пакетами (монохранилищами)

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

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

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

    Для решения этой проблемы было создано сообществоlernaБиблиотека помогает нам управлять всеми пакетами, добавляя lerna.json. Со стороны пряжи вводится понятие, называемое рабочим пространством. Поэтому в этом плане должен выиграть yarn, но npm и lerna тоже могут выполнить это требование.

  3. Скорость установки

    Одной из самых критикуемых проблем с npm является скорость его установки. Для некоторых проектов, от которых многое зависит, установка npm занимает 5-10 минут и более. Суть этой проблемы в том, что npm использует последовательный метод установки, один устанавливается перед другим. В ответ на это пряжа была установлена ​​параллельно, что значительно ускорило установку.

  4. Доступно в автономном режиме

    Yarn по умолчанию поддерживает автономную установку, то есть однажды установленный пакет останется на компьютере (доступ к расположению кеша можно получить черезyarn config set yarn-offline-mirrorуказан). Затем установите его снова и скопируйте напрямую.

    В начале npm делал все запросы по сети (для поддержания актуальности), но позже он также позаимствовал у yarn для создания кеша. Начиная с npm 5.x мы можем использоватьnpm install xxx --prefer-offlineПриходитьприоритетиспользовать кеш (это означает, что кеш больше не отправляет сетевые запросы) илиnpm install xxx --offlineПриходитьполностьюИспользуйте кеш (это означает, что установка не удалась без кеша).

  5. информация о консоли

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

    Однако npm 5.x также удалил это дерево. Это еще один пример взаимного обучения и совершенствования.

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

постскриптум

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

Справочная статья

Категории