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

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


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

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

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


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

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


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

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

0

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

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

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


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


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

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


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

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

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

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

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

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

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

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

+1

Проблема возникает когда какой-нибудь модуль прописывает свои зависимости используя 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) это плохая практика.

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

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

+1

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

0

Более того видно что например "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 помогает в этом).

0

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


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


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

0

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


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

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


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

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

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

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

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

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

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

+1

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


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

+1

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


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

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

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

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

0

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

0

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

0

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

+2

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


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

0

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

0

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

0

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


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

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

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


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

0

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

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

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

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


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


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

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

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

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

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


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

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

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

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

0

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

0

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

0

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


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


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

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

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


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


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

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

0

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

0

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

+2

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


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

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

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


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

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

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

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

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

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

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


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

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

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

0

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


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


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

0

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

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

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

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

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