Комментарии 113
— А как же ***?
— Чувак *** — прошлый век, сейчас 2017 год, все используют Yarn!
Ну неужели нельзя было это всё в NPM законтрибутить?! Опять перекрашивать стены зоопарка из-за этих хипстеров.

NPM — проект с большой и долгой историей (c 2010 года). Нельзя просто так взять, и прислать pull-request на 10 000+ измененных строк.


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

Фронтенд-фреймворки меняем каждые пол-года, так теперь еще и пакетные менеджеры придется?
Всё правильно делают, на самом деле. В моей компании отказались от NuGet по похожим причинам.
Подписываюсь под просьбами рассказать подробней. Не минусовал, если что)
Отсутствие единого представления изолированного продукта (помимо checkout нужно ещё и собрать проект), три точки зависимости вместо одной (репозиторий, менеджер пакетов, приватный источник пакетов), медленная скорость всего этого и большое потребление интернет-полосы (600 МБ зависимостей каждый раз перекачивать через наци-компанию надоело). Сам NuGet ещё любит «случайно» не обновить какой-нибудь пакет или наоборот внезапно обновить что-нибудь. Коммитить всё в репозиторий оказалось проще и надёжнее.
У нас противоположный опыт использования собственного NuGet-репозитория. Действительно, добавление еще одной точки отказа может привести к проблемам, но преимуществ оказалось больше. Возможно дело в специфике проектов. Никаких «случайных» обновлений не замечено.
А эти же 600 МБ теперь тоже тянутся, но из VCS?

А мы наоборот пришли к схеме с приватными репозиториями и живём счастливо.
Т.е. есть dev/qa/production ветки, откуда берутся пакеты при сборке на соответствующей среде и ещё есть shared ветка, куда руками ответственных людей перекладываются пакеты из nuget.org. Все ci-сервера смотрят только на локальные ветки. Таким образом трафик только локальный, все билды используют только approved-пакеты и не в состоянии "случайно" использовать какой-то не такой пакет.
Т.е. разработчик в новом проекте, конечно, может взять что угодно из nuget.org, но первый же билд на dev-среде упадёт и ему придётся "защищать" используемые пакеты, чтоб их втащили на shared.
Меньше велосипедов, унификация компонентов и тд…
В рамках VCS все legacy-связи потихоньку отрезаются и переводятся на пакеты. Проблем в разы меньше становится.


Коммитить всё в репозиторий — это имеется ввиду, что зависимости прям тут же бинарниками лежат и таскаются тоннами при чекаутах? Отличное решение, чо. Как помножил это всё на количество проектов — как-то даже страшновато стало. Чтоб когда ci-билд тригерится на каждый коммит, а чекаут тащит всё это барахло — эти люди ещё что-то про трафик будут говорить?

600 МБ зависимостей каждый раз перекачивать через наци-компанию надоело


Я не знаком с NuGet, поэтому может задам глупый вопрос.
У NuGet нет такого же локального кэша, как, например, у Maven?

Есть он, есть. И даже можно внутренний репозиторий nuget поднять.

Похоже фейсбук решил окончательно захватить мир. Помнится лет 5 назад в плане опенсорса я вообще ничего о них не слышал, а сейчас React, GraphQL, Atom, Yarn, ещё целая куча всякого интересного. Молодцы в общем))

В случае NPM, в зависимости от подключенных модулей, каталог node_modules мог сильно отличаться от машины к машине.

А они как хотели, чтоб он был везде одинаковый, независимо от подключенных модулей?)


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


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

Мне искренне интересно, какие такие у них с npm проблемы возникли. Вроде бы npm install react --save — не rocket science, не?


Множественные репозитории, retry on fail, кэширование установленных пакетов — это все мило, но не киллер-фича.

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

Это проблему должен был решить shrinkwrap замораживая всё дерево зависимостей — но с ним проблема, что он по разному на каждой системе генерируется + избыточный формат (у нас был на 3 мегабайта json + дифы не читались в принципе если чтото обновляешь минорное или даже перегенерируешь + падает переодически с неочевидными ошибками)

Понятно, спасибо. Я не сталкивался с проблемами зависимостей 2 порядка.

Там еще и проблемы более высоких порядков вылазят иногда (:

А я сталкивался и не один раз. Но самом деле можно делать оверрайд зависимостей второго порядка (неявных) и также фиксировать версии — Shrinkwrap, но это неудобно очень (конфиг файл большой). Я делаю немного по другому (кешрую весь каталог nmp_moules, для этого есть готовые тулзы всякие) ну и всегда указываю версии явно без всяких ~^ и тд.

А я сталкивался и не один раз.

А расскажите? Чтоб я знал, к чему готовиться.

Проблема возникает когда какой-нибудь модуль прописывает свои зависимости используя Semantic Versioning range фичи (^~ и прочий бред). В итоге возникают ситуации когда модуль тянет новую версию по неявно указанной зависимости, версию с которой он не способен работать нормально.


Пример https://github.com/miickel/gulp-angular-templatecache/issues/124 Вот фикс https://github.com/miickel/gulp-angular-templatecache/pull/125/commits/9c306a3898f7f33c0f55d5a909119fe5126e918d


Использую гугл сможете найти много информации о том что указание неявной версии зависимостей (чифа Semantic Versioning) это плохая практика.

"gulp-header": "1.x"
указание неявной версии зависимостей

Теперь понятно, почему я с этим никогда не сталкивался:)

Не обязательно так вот жестко в виде 1.x, бывают и другие сайд эффекты.

Более того видно что например "gulp-util": "3.x" так и остался с указанием неявной версии https://github.com/miickel/gulp-angular-templatecache/pull/125/commits/9c306a3898f7f33c0f55d5a909119fe5126e918d То есть они сделали фикс не осознавая проблемы целиком. Хотя в текущей мастер ветке версии уже указаны фиксировано что правильно — https://github.com/miickel/gulp-angular-templatecache/commit/9ddb88ab4fd778f641eb8e2c59ee2532ba3747d7#diff-b9cfc7f2cdf78a7f4b91a753d10865a2


То есть всегда следует указывать версии фиксированно, а обновлять верси руками (npm-check-updates помогает в этом).

На самом деле можно нормально использовать semantic version range.
Если автор библиотеки не релизит ее по semver, то его за это надо пинать.


В вашей конкретной ситуации виноват автор gulp-header, за то, что выпустил версию без обратной совместимости.


В качестве бонуса semver вы получаете простые багфиксы. Например нашелся баг в библиотеке A, от которой вы зависите через C -> B -> A. Из-за тривиального фикса, B и C тоже вынуждены релизить свои библиотеки. Гибкий диапазон версий избавляет от рутинного микроменеджмента. Если авторы следуют правилам, конечно.

Вы не так поняли, я не против использования semantic versioning в целом, но против использования его range фичей и неявного указания версий в зависимостях. Я убедился что в завиимостях всегда нужно указывать версии явно, всегда, и обновленния делать вручную (npm-check-updates помогает).


В вашей конкретной ситуации виноват автор gulp-header, за то, что выпустил версию без обратной совместимости.

Это был очень явный пример который я сразу поэтому и вспомнил, случай далеко не единичный. В том то и дело что благодаря использованию semantic versioning range фичей команда npm install не дает одинаковый результат при исполнении в разное время! По моему глубокому убеждения команда должна давать одинаковый результат и использования кеширования всего npm_modules каталога (допустим имя файла кеша берется по хешу от package.json) + явное указание версии приближает поведение исполнения команды к желаемуму поведению.


Если авторы следуют правилам, конечно.

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

> А они как хотели, чтоб он был везде одинаковый, независимо от подключенных модулей?)
Одинаковый, с замороженными версиями.
Для npm есть костыль shrinkwrap, который решает эту проблему, но не уметь такое по дефолту — просто стыдно.

> я был уверен, что npm install при существующем package.json дает идемпотентный результат
Не дает.

> так версии можно жестко фиксировать.
И лишиться возможности обновления, зафиксировав все зависимости до патч-версий? (Если не пользоваться shrinkwrap-подобными костылями)

> Мне искренне интересно, какие такие у них с npm проблемы возникли
https://github.com/npm/npm/issues
А они как хотели, чтоб он был везде одинаковый, независимо от подключенных модулей?)
наверное как в композере: composer.lock — файл со списком замороженных версий. Команда
composer install ставит версии прописанные в composer.lock не трогая его (если он был, конечно)
composer update — обновляет composer.lock и ставит последние подходящие под номенклатуру composer.json версии

В общем, судя по скриншотам из оригинальной статьи, я понял, что фэйсбуку просто не хватало сран вездесущих эмодзи в npm, а npm i -S слишком долго набирать, yarn add куда быстрее. Ну и ещё естественно npm обладал для них фатальным недостатком.

Важное отличие yarn, что он работает гораздо быстрее. Я проверил на рабочем проекте, он устанавливает модули за 30 секунд, а npm делал за 90.


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

То что быстро — это хорошо.


Однако оно видимо не умеет читать настройки из .npmrc. У меня в этом файле прописан адрес локального репозитория для своих алиасов. Беглый осмотр доков ничего не дал. Так что пока заменить npm для меня оно точно не сможет.

>он устанавливает модули за 30 секунд, а npm делал за 90.

Это круто! — Отлить не успеешь.

Ну это в 3 раза быстрее. А если зависимостей много, npm может всё ставить минут 5, и это далеко не предел

Разве модули не ставятся в проект всего 1 раз, после клонировании репозитория?

Локально долгая установка не проблема.
Но во время билда, все ставится и собирается с нуля, поэтому быстрая установка == быстрый билд

И как инкрементальные билды спасут от долгой установки зависимостей? У меня фронтенд-проект, сборщики сами ставятся через npm, как и непосредственно и сами зависимости самого проекта. Конечно можно каждый раз не удалять node_modules из сборочной директории, но раз-два в месяц бывает, что локально всё собирается, а на сервере — нет. И это именно из-за разных версий пакетов.

Что такое инкрементальный билд?


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

Решил проблему на нашем дженкинсе добавлением --cache-min Infinity

--cache-min Infinity не решает проблему, это большой костыль. Я тоже так начинал, но в итоге пришлось использовать сторонние тулзы для кешрования, я их кучу перепробывал — остановился на https://github.com/swarajban/npm-cache (интегрировал в Maven сборку).

Была довольно серьезная проблема с резолвом пакетов новых версий, но ее закрыли, кажется в 3.9. После этого обновления и еще добавления prune стало работать вполне сносно. У нас тоже maven как раз и что-то мне сильно не хотелось кэширующий прокси в процесс добавлять, с учетом того что сборка на дженкинсе и локальной ноды там нет и не сильно нужна.


Если снова вылезут проблемы — попробую npm-cache.

кэширующий прокси в процесс добавлять

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


PS npm-cache не содержит в себе сервер, это просто по сути копи паст каталога с архивированием.

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

Простите, но сколько раз за день вам (ну или бэк команде) требуется свежая сборка с CI? Ну правда?
Мы вот когда перешли на вебпак, время сборки выросло с 10 минут до 2 часов (ага)! После оптимизаций сократилось до 20 минут, из которых чистый нпм занимает ну примерно 6-7. Т.е. как бы лишние пару минут погоды то не сделают.
Но нет, даешь новый пакетный менеджер с котами и эмодзи!

PS извиняюсь за крики, накипело уже

Что именно у вас накипело?


У нас в команде воркфлоу с пулл-реквестами. И разработчики не любят ждать, когда отправили код на ревью, люди код посмотрели, а мерджить нельзя, все ждут билда.


Поэтому мы стараемся, чтобы тесты на пулл-реквест не занимали дольше 10 минут. Если будет на 2 минуты быстрее, то процессы заработают лучше, а производительность команды возрастет.

Ну да, кстати. Машинально об этом не подумал, так как у нас их столько, что уже смирились что-то быстро в девелоп-ветку сливать. Пока ревьюишь остальные, билд уже соберется. Ну… Или не соберется :)

UPD накипело желание крупных игроков навязать свои инструменты вместо решения проблем существующих
К вам Facebook пришел домой и под угрозой расправы заставляет переходить на yarn?
Нет, к счастью, просто не хочется в один прекрасный момент увидеть проект с кастомным конфигом для yarn, который нельзя нормально поставить/использовать через npm. Как это было в самом начале с bower, где не было package.json.
Откуда столько боли? От необходимости поддерживать и npm, и bower на проектах, из-за того, что npm не умеет в семвер на гитхаб. Вот и опасаюсь, как бы не вышло, что нужно будет поддерживать еще один чудный пакетный менеджер.

Ну да, я параноик =(

Ваши подозрения вполне оправданы. Никто не хочет поддерживать еще один способ установки для своих библиотек.


Надеюсь, в Facebook это тоже понимают и декларацию зависимостей в package.json ломать не будут.
Все же опыт противостояния npm vs bower не прошел даром.

Не понимаю возмущения. Объясните дураку. Это же клиент хранилища npm, а не новое хранилище. То есть вряд ли там даже стали что либо переименовывать, кроме npm -> yarn и, вероятно, некоторых опций.
Это примерно как если бы yum сделали не таким капризным ко сборкам из исходников, а то последний после установки чего-то из сорсов (и потом удаления всех упоминаний об этом) толком не ставит пакет: строчки ползут, ошибок нет, но и де-факто почти ничего не ставится. Ну, тут, вероятно, я чего-то не знаю о yum, тем не менее.
Да, все прекрасно, но где-то в начале комментов уже спросили, почему все эти оптимизации нельзя было сделать в самом npm? Видимо, там PR с эмодзи бы не приняли.

а не новое хранилище
Я искренне надеюсь, что фейсбуку по душе npm-registry. Не дай бог, не дай бог.

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

npm ничего не тормазит присборке CI, просто кто-то не умеет (не хочет, не видит необходимости) кешровать модули грамотно.

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

То, что кеширование это костыль?


Процесс npm install должен быть однозначным и воспроизводимым. Кеширование node_modules усугубляет ситуацию.


По идее, кеширование модулей происходить где-то внутри npm, у него даже есть папка ~/.npm с общим кешем модулей, только устанавливать быстрее это ему не помогает

Процесс npm install должен быть однозначным и воспроизводимым. Кеширование node_modules усугубляет ситуацию.

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


Кроме этого некоторые модули имеюи бинарные зависимости, которые вытягиваются в зависимости от OS.


По идее, кеширование модулей происходить где-то внутри npm, у него даже есть папка ~/.npm с общим кешем модулей, только устанавливать быстрее это ему не помогает

Не по идее, это факт что npm имеет свой кеш, но он ОЧЕНЬ кривой.

Именно поэтому я рад появлению yarn с правильным кешем, который делает разворачивание node_modules c нуля очень быстрым и избавляет меня от дополнительных наворотов (за исключением самого yarn, но здесь замена npm -> yarn выглядит справедливой)

"Я использую" и "компания на которую я работаю использует" не всегда согласующиеся вещи.

Нет, ведь зависимости могут добавляться/удаляться, их версии изменяются и т.д. А ещё полезно бывает время от времени удалять node_modules и ставить всё заново, так как иногда могут возникать странные вещи. Порой даже добавление 1-го пакета может занимать минуту.


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

А есть объяснение, почему символом стал котик? Не могу найти у них эту информацию.
Yarn дословно в переводе с английского «пряжа», т.е. ассоциативный ряд построен на клубке пряжи (ниток) и, соответственно, символ — котик.
Нужно будет на выходных пересобрать какой то проект с помощью этого чуда юда…
а где-то сказано, что оно через npm ставится? на сайте предлагают curl'ить

jspm немного другую задачу решает. Тут проблема в том, что метод разрешения зависимостей в nodejs требует несколько IO-операций, что нормально при синхронном подключении модулей и не очень — при асинхронном, как мы это делаем в браузере. jspm решает эту проблему, запоминая для каждого модуля его точку входа.


yarn про другое (а про что именно, пока что не очень понятно).

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

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

С фреймворками поигрались, теперь за менеджеры пакетов взялись?
Забавно, что Фейсбук это как бы зло с социальной точки зрения, но с технологической точки зрения их основные продукты очень хороши и удобны. Они как бы говорят программисту: «Приходи на темную сторону, у нас есть крутые разработки»

Я правильно понял, что нужно только изменить npm install на yarn install?
Мой вебпак не сломается?

НЛО прилетело и опубликовало эту надпись здесь
Не продуктивно использовать сырой продукт или сырую идею. Креативно, но жутко контрпродуктивно)

Конечно, лучше подождать до "сервис-пака" перед использованием в продакшене.


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

НЛО прилетело и опубликовало эту надпись здесь

А что не так-то? Смысл Deprecated как раз в этом — так писать еще можно, но уже не рекомендуется.

Это была одна из проблем npm by design — можно партизански устанавливать пакеты без сохранения в package.json. Локально у разработчкика все работает, а другие члены команды этот модуль не видят.


Глобальная установка тоже нерекомендуемый паттерн. Все нужные для проекта CLI-утилиты можно устанавливать локально, они попадут в node_modules/.bin. Более того, если у вас в package.json в секции scripts написано "test": "gulp test", то локально установленный gulp автоматически подложится в PATH, никакого оверхеда по сравнению с глобальным. В то время как на linux для глобальной установки нужен sudo, эта фича вообще спасение.


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

Тем не менее, есть исключения. npm, yarn и bower лучше все же ставить глобально :)

Локально у разработчкика все работает, а другие члены команды этот модуль не видят.

Человек всегда слабое звено, любую систему можно поломать человеческой глупостью и отстствием ответственности. Кто на прописал все зависимости в package.json тому по рогам настучасть тк не понимает воркфлоу.

>Это была одна из проблем npm by design — можно партизански устанавливать пакеты без сохранения в package.json. Локально у разработчкика все работает, а другие члены команды этот модуль не видят.

«перестаньте за меня думать» ©
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.