Как выбрать вариант отверждения пряжи или npm

предисловие

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

Семантическое управление версиями npm

Для npm информация о зависимостях отражается в зависимостях package.json, где используется Semver (семантический контроль версий).Спецификацию семантического управления версиями можно найти в. Общие рекомендации таковы:

Версия программного обеспечения обычно состоит из трех цифр, например: X.Y.Z.
Версии строго увеличиваются, здесь: 16.2.0 -> 16.3.0 -> 16.3.1
Когда выпущена важная версия, могут быть выпущены альфа, rc и другие предыдущие версии.
За измененными версиями ключевых слов, таких как альфа и rc, может следовать время и метаинформация.

Формат версии:

Издатели должны быть обеспокоены правилами формата версии.

主版本号.次版本号.修订号

Правила увеличения для разных номеров версий следующие:

Основной номер версии (major): когда вы вносите несовместимые изменения API,
Второстепенный номер версии (второстепенный): когда вы добавляете обратно совместимые функции, это можно понимать как версию функции.
Номер редакции (патч): Когда вы вносите исправление для обратной совместимости, его можно понимать как версию с исправлением ошибок.

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

контроллер версий

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

{ "dependencies" :
  { "foo" : "1.0.0 - 2.9999.9999",// 大于等于1.0.0 小于 2.9999.9999
  "bar" : ">=1.0.2 <2.1.2", // 比较清晰  左闭右开
  "baz" : ">1.0.2 <=2.3.4", // 左开右闭
   "boo" : "2.0.1", // 规定版本  
   "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0", // 表达式也算清晰
   "asd" : "http://asdf.com/asdf.tar.gz"// 指定下载地址代替版本
    , "til" : "^1.2.3"// 同一主版本号，不小于1.2.3 即 1.x.y  x>=2 y>=3
  , "elf" : "~1.2.3" // 同一主版本和次版本号 即1.2.x x>= 2
  , "two" : "2.x" // 这个比较形象，x>=0  即2.0.0 以上均可
  , "thr" : "3.3.x" // 同上 x>= 0  即3.3.0 以上
  , "lat" : "latest" // 最新版本
  , "dyl" : "file:../dyl" // 从本地下载
  }
}

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

npm install использует ^ по умолчанию

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

вопрос

Несогласованные зависимости в разных средах

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

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

Следовательно, потребуется следующая затвердевшая версия, то есть заблокированная версия.

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

Исправленная версия

Версия с фиксированной линией, есть следующие три способа:

npm-shrinkwrap.json

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

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

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

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

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

// 生成依赖  默认不包括dev dependencies
npm shrinkwrap
// 将dev-dependencies计算在内
npm shrinkwrap--dev

package-lock.json

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

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

1. версия npm 5.0.x,Как бы ни менялся package.json, npm я его скачаю по файлу блокировки.

2. После версии 5.1.0npm install будет игнорировать файл блокировки для загрузки последнего пакета npm

3. Версия 5.4.2Если package.json изменен, а файлы package.json и lock отличаются, выполнитеnpm iВ это время npm загрузит последний пакет в соответствии с номером версии и семантическим значением в пакете и обновит его до блокировки. Если оба находятся в одном и том же состоянии, выполнитеnpm iОн будет загружен согласно блокировке, независимо от того, новая ли версия фактического пакета пакета.Содержание этого абзаца относится к пользователям Zhihu. Для получения подробной информации перейдите по ссылке https://www.zhihu.com/question/264560841.

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

неплоские зависимости

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

// 顶层声明了loader-utils的依赖，版本为1.0.4
  "loader-utils": {
      "version": "1.0.4",
      "resolved": "http://r.npm.sankuai.com/loader-utils/download/loader-utils-1.0.4.tgz",
      "integrity": "sha1-E/Vhl/FSOjBYkSSLTHJEVAhIQmw=",
      "requires": {
        "big.js": "^3.1.3",
        "emojis-list": "^2.0.0",
        "json5": "^0.5.0"
      }
    }
    }

Для зависимостей верхнего уровня, которые соответствуют требованиям, больше не устанавливаются,

"sass-loader": {
      "version": "7.1.0",
      "resolved": "http://r.npm.sankuai.com/sass-loader/download/sass-loader-7.1.0.tgz",
      "integrity": "sha1-Fv1ROMuLQkv4p1lSihly1yqtBp0=",
      "dev": true,
      "requires": {
         // ^1.0.1 顶级依赖满足需求
        "loader-utils": "^1.0.1"
      }
    }

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

"less-loader": {
      "version": "4.1.0",
      "resolved": "http://r.npm.sankuai.com/less-loader/download/less-loader-4.1.0.tgz",
      "requires": {
        // 1.0.4 不满足 ^1.1.0
        "loader-utils": "^1.1.0",
      },
      "dependencies": {
        "loader-utils": {
          "version": "1.2.3",
          "resolved": "http://r.npm.sankuai.com/loader-utils/download/loader-utils-1.2.3.tgz",
          "integrity": "sha1-H/XcaRHJ8KBiUxpMBLYJQGEIwsc=",
          "dev": true,
          "requires": {
            "big.js": "^5.2.2",
            "emojis-list": "^2.0.0",
            "json5": "^1.0.1"
          }
        }
     }
    }

Разница между Package-Lock.json и NPM-Shrinkwrap.json

Package-lock.json не будет опубликован на NPM, а NPM-Shrinkwrap будет публикацией по умолчанию
Пакет без верхнего уровня - Lock.json будет игнорироваться, а то же состояние файла SCRINKWRAP сохраняется.
npm-shrinkwrap.json поддерживается в версиях npm 2,3,4, package-lock.json представлен после npm5
Оба существуют одновременно, npm-shrinkwrap.json имеет приоритет над package-lock.json

yarn.lcok

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

синтаксис пряжи

Yarn использует формат, разработанный самостоятельно, который немного похож на YAML по синтаксису (стандартный YAML будет использоваться в Yarn 2.0). Строки, начинающиеся с #, являются комментариями.

В первой строке записывается имя пакета и его семантическая версия (определяется package.json).

Нижеследующие имеют отступ, указывая на то, что это информация пакета.

Поле версии записывает точную версию пакета.

Разрешенное поле записывает URL-адрес пакета. Кроме того, значение в хеше равно шасуму. Шасум, записанный Yarn, берется из версий [:версия].dist.shasum пакета (доступен вручнуюregistry.npmjs.org/:packageПолучите JSON, разберите этот JSON, чтобы получить)

dependencies записывает зависимости пакетов. Возможно, зависимости пакета все еще имеют зависимости, но они не будут здесь документированы. Следующим образом:

pkg-dir@^1.0.0:
  version "1.0.0"
  resolved "http://r.npm.sankuai.com/pkg-dir/download/pkg-dir-1.0.0.tgz#7a4b508a8d5bb2d629d447056ff4e9c9314cf3d4"
  integrity sha1-ektQio1bstYp1EcFb/TpyTFM89Q=
  dependencies:
    find-up "^1.0.0"

pkg-dir@^2.0.0:
  version "2.0.0"
  resolved "http://r.npm.sankuai.com/pkg-dir/download/pkg-dir-2.0.0.tgz#f6d5d1109e19d63edf428e0bd57e12777615334b"
  integrity sha1-9tXREJ4Z1j7fQo4L1X4Sd3YVM0s=
  dependencies:
    find-up "^2.1.0"

pkg-dir@^3.0.0:
  version "3.0.0"
  resolved "http://r.npm.sankuai.com/pkg-dir/download/pkg-dir-3.0.0.tgz#2749020f239ed990881b1f71210d51eb6523bea3"
  integrity sha1-J0kCDyOe2ZCIGx9xIQ1R62UjvqM=
  dependencies:
    find-up "^3.0.0"

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

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

Документировать зависимости зависимостей Как было сказано выше, зависимости зависимостей не записываются напрямую под информацию о зависимостях — они поднимаются, что упрощает весь yarn.lock, а когда зависимости установлены, с ними еще и проще иметь дело, потому что у вас нет иметь слой Один уровень вложенности используется для поиска информации о зависимых зависимостях.
Легко разрешать конфликты версий зависимостей Конфликты версий зависимостей неизбежны.Конечно, иногда это не конфликт версий, а просто другая запись версии в семантическом формате версии. Например, ^5.0.0 не противоречит 5.x.x много раз, поэтому информацию можно объединить. Такие как:

chalk@^2.0.0, chalk@^2.0.1:
  version "2.3.2"
  resolved "https://registry.yarnpkg.com/chalk/-/chalk-2.3.2.tgz#250dc96b07491bfd601e648d66ddf5f60c7a5c65"
  dependencies:
    ansi-styles "^3.2.1"
    escape-string-regexp "^1.0.5"
    supports-color "^5.3.0"

Обратите внимание на первую строку, yarn.lock записывает ^2.0.0 и ^2.0.1, а при добавлении меловой зависимости последней версией, соответствующей семантической версии, является 2.3.2 (поле версии), эта версия ^2.0. требования .0 и ^2.0.1 выполнены, поэтому информацию можно объединить.

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

Должна ли быть заблокирована версия

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

1. Все проекты в группе полагаются на набор инструментов, разработанный ими самими.

2. Этот класс инструментов основан на некоторых сторонних пакетах с открытым исходным кодом.

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

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

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

Должен ли .gitignore игнорировать файлы блокировки

Должен ли он упаковать - lock.json не должен быть включен .gitignore, вы можете посмотреть, чтобы объяснить StoneCipher Jun Gangster: Если вы используете механизм блокировки, Package-Lock.json должен быть отправлен в REPO. Например, Vue принял политику. Если вы не используете механизм блокировки, вы должны присоединиться к содержимом файла .npmrc Package-lock = false и отправлено в REPO. Например, Eslint принял политику.

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

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

заключительные замечания

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

документы The Horse Plus.com/files/crackka…

nuggets.capable/post/684490…
stackoverflow.com/questions/4…

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