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

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

Вы можете прочитать актуальную проблему Github, которую я создал: https://github.com/palantir/blueprint/issues/3254

Эта ошибка будет постоянно появляться всякий раз, когда этот компонент, вызывающий эту функцию, будет монтироваться. Оказалось, что у нас была конфликтующая вложенная версия React, установленная внутри наших node_modules. Так как же это случилось? После некоторых исследований выяснилось, что эта конфликтующая версия React устанавливается только при запуске yarn install. Удаление моих node_modules и запуск npm install reliably установили мои зависимости правильно, что привело к исчезновению этой ошибки. С этим новым открытием я вынужден заставить мою команду перейти с Yarn на NPM. Это побудило меня больше узнать о различиях между этими двумя системами управления пакетами.

Рассматривая эту проблему, полезно оглянуться назад и понять, что сделало Yarn привлекательной альтернативой для начала. Я свел это к двум важным причинам. Скорость и автоматически созданный файл блокировки. Давайте поговорим о более сложном из двух; yarn.lock

Что такое файл блокировки

Допустим, вы работаете над проектом и у вас установлена ​​версия 1.4.0 «Foo» в качестве зависимости. В вашем файле package.json у вас есть «Foo», указанная как зависимость с использованием semver: "Foo": ^1.0.0. Вы разрабатываете свою функцию и отправляете ее в удаленную ветку. Затем ваш коллега извлекает вашу функцию, запускает npm install, но функция, которую вы только что создали, не работает. Вы просто смотрите на него, пожимаете плечами и говорите: «Это работает на моей машине». После некоторого расследования вы обнаружите, что у вашего коллеги установлена ​​версия 1.7.0 «Foo», которая немного отличается от предыдущей версии 1.4.0, которую вы использовали при разработке. Поскольку пакет использует ^symbol в вашем package.json, он установит последнюю минорную версию, поэтому ваш коллега использует версию 1.7.0, когда он запускал `npm install`. Чтобы избежать этой проблемы, вам нужно явно указать версию каждого пакета в вашем package.json. Вот это боль. Здесь на помощь приходит файл блокировки.

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

Это нововведение было очень привлекательным, и разработчикам на него приходилось меньше беспокоиться. Однако, начиная с NPM v5.0.0, NPM автоматически создает собственный файл блокировки, который делает то же самое. Yarn сделал это первым, но сегодня это вряд ли является «преимуществом» перед NPM.

Скорость

Когда Yarn ворвался на сцену, он разрекламировал, что он почти в два раза быстрее, чем NPM. Что БЫЛО правдой. Пряжа была намного быстрее и сэкономила много времени. Однако так ли это и сегодня? Нет не правда. Я не могу дать вам никаких тестов, но я умоляю вас проверить это самостоятельно. Удалите ваши node_modules или пакет и снова установите его с помощью NPM и Yarn. Пряжа быстрее? Да, конечно. Это вдвое быстрее? Ни за что.

Вывод

После анализа Yarn Vs. В этом свете я не вижу особой пользы от использования Yarn. Конечно, он по-прежнему устанавливает пакеты немного быстрее, чем NPM, но цена, которую он это делает, того не стоит. Из-за этой стоимости я начал писать эту статью. Как я упоминал в начале, переустановка моих node_modules с использованием NPM вместо Yarn устранила этот странный конфликтующий экземпляр React, живущий внутри моих node_modules. Точная причина того, почему это происходило, довольно глубока, и я сомневаюсь, что когда-нибудь узнаю, что именно, но она проливает свет на одно из самых больших преимуществ NPM; Он просто более зрелый, поддерживается большим сообществом и более надежен, чем Yarn. Пряжа все еще относительно новая, может быть, в ближайшем будущем она внесет большие инновации с новой обязательной функцией, но сейчас я думаю, что вернусь к старым верным.

Примечание. Если вам нужно подробное объяснение того, как работает NPM и управление пакетами, ознакомьтесь с этой замечательной статьей Alexis King