Facebook и Google выпустили Yarn, новый менеджер пакетов для JavaScript

  • Новость


Вчера вечером Facebook официально анонсировала новый пакетный менеджер для JavaScript под названием Yarn. На одной из стадии разработки к проекту подключились компании Google, Exponent и Tilde.

«Самый популярный менеджер пакетов JavaScript — это NPM. Он обеспечивает доступ более чем к 300 тысячам пакетов. Используют его более 5 миллионов разработчиков, а ежемесячно к нему обращаются для загрузки более 5 миллиардов раз.

Мы успешно использовали NPM в Facebook в течение многих лет, но так как объем нашего кода и число разработчиков выросло, мы столкнулись с проблемами последовательности, безопасности и производительности. После попытки решить все эти вопросы, мы пришли к намерению создать собственное решение, чтобы обеспечить надежность управления разработкой. Итогом этой работы стал Yarn — быстрая, надежная и безопасная альтернатива клиенту NPM», — говорится в официальном блоге Facebook о новинке.

Разработчики Facebook утверждают, что Yarn все так же позволяет получить доступ к пакетам NPM, но при этом позволяет быстрее и последовательно управлять зависимостями между машинами, или работать в защищенной среде в автономном режиме. Это, по мнению создателей Yarn, позволит разработчикам сосредоточиться на том, что на самом деле важно — на создании новых продуктов и функций. Вот перечень основных отличительных особенностей Yarn:

  • автономный режим;
  • детерминированность;
  • производительность сети;
  • наличие нескольких реестров;
  • сетевая гибкость;
  • наличие Flat Mode;
  • больше эмодзи (и с котиками тоже).

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

Разработчики оригинального NPM — коммерческая организация, которая была в курсе создания и скорого выхода в свет конкурента. Однако, бизнес-модель проекта построена не вокруг клиента, а вокруг каталога, который также используется и Yarn. Поэтому новинка от Facebook и Google не представляет для них большой угрозы.

Команда Facebook решила вынести свою разработку за пределы внутреннего репозитория компании и выложила Yarn на GitHub, где можно ознакомиться с проектом и принять участие в разработке.
Поделиться публикацией
Комментарии 113
    +51
    — А как же ***?
    — Чувак *** — прошлый век, сейчас 2017 год, все используют Yarn!
      +6
        +2

        yarn все итак давно используют. а тут фигня какая-то.

        +16
        Ну неужели нельзя было это всё в NPM законтрибутить?! Опять перекрашивать стены зоопарка из-за этих хипстеров.
          +4

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


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

          +11
          Фронтенд-фреймворки меняем каждые пол-года, так теперь еще и пакетные менеджеры придется?
            0

            show must go on

            –4
            Всё правильно делают, на самом деле. В моей компании отказались от NuGet по похожим причинам.
              0
              А можно поподробнее?
                0

                От NuGet как менеджера или от паблик реестра пакетов?

                  +5

                  А с 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 поднять.

                        +1
                        А потом умрет так же, как и прочие сервисы гугла
                          0
                          Там есть Facebook.

                          Так что есть надежда что будет жить. :-)
                            +1
                            Скажите это пользователям Parse.
                              +1
                              Хм, — И на старуху… ;-)
                          0

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

                            +7

                            Atom от GitHub же. А остальное — да.

                              –3

                              Точняк))

                                +1
                                Возможно речь о вот этом наборе надстроек: Nuclide
                              +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"
                                            указание неявной версии зависимостей

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

                                            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

                                                Инкрементальные билды уже не в моде?..

                                                  0

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

                                                    +2

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


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

                                                      0

                                                      npm prune?

                                                    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 ничего не тормазит присборке 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
                                                          + потестил у себя, npm = 79 секунд, yarn 24. результат отличный
                                                            0
                                                            аналогично. NPM — 1:45, Yarn — 0:25
                                                          0
                                                          А есть объяснение, почему символом стал котик? Не могу найти у них эту информацию.
                                                            +4
                                                            С котиками все лучше.
                                                              0

                                                              Суп котик тоже не должен испортить я полагаю.

                                                              +6
                                                              Yarn дословно в переводе с английского «пряжа», т.е. ассоциативный ряд построен на клубке пряжи (ниток) и, соответственно, символ — котик.
                                                                0
                                                                Спасибо, добрый человек!
                                                                  +1
                                                                  А у вас котик на аватарке! КО.
                                                                    +3
                                                                    Потому и спрашивал. Профессиональный интерес.
                                                              0
                                                              Нужно будет на выходных пересобрать какой то проект с помощью этого чуда юда…
                                                                +5
                                                                У меня нет сил уже… ну сколько можно?
                                                                  +5
                                                                  Меня смущает одно:

                                                                  npm install -g yarn
                                                                  yarn
                                                                    +1
                                                                    а где-то сказано, что оно через npm ставится? на сайте предлагают curl'ить
                                                                      0

                                                                      В оригинальной статье и сказано, в разделе Getting started

                                                                      0

                                                                      Не только. Смотрите:
                                                                      https://yarnpkg.com/en/docs/install


                                                                      Есть deb, rpm и tar.gz для всех остальных

                                                                      +2

                                                                      Хм. jspm уже закапывать? Я же только с voloBowernpm слез.

                                                                        0

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


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

                                                                          0
                                                                          Пришёл Facebook — открывай ворота. (С)
                                                                          +3

                                                                          Кто сможет сказать, bower еще 2016 актуальный?

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

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

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

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

                                                                                      0

                                                                                      Ну да. Не должен

                                                                                        0

                                                                                        только не yarn install, а просто yarn.

                                                                                        0
                                                                                        Пока не понятно, много багов, вообще не приспособлен к миграции.
                                                                                        Например как и куда мне gulp, gulp-cli поставить?
                                                                                        yarn install --dev gulp gulp-cli

                                                                                        -g я так понял из хелпа deprecated

                                                                                        ну ок, но дальше вообще жесть:
                                                                                        yarn add express ejs semantic-ui

                                                                                        и прощай yarn, там происходит какой-то эксепшен и приплыли.

                                                                                        Короче он не юзабелен, автор ты точно уверен что это для всех а не для внутренних нужд компании?

                                                                                          +3

                                                                                          yarn global add gulp-cli поставит вам gulp глобально


                                                                                          Документация: https://yarnpkg.com/en/docs/cli/global


                                                                                          и прощай yarn, там происходит какой-то эксепшен и приплыли.

                                                                                          Это неконструктивно. Я воспроизвел вашу проблему и зарепортил баг:
                                                                                          https://github.com/yarnpkg/yarn/issues/976

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

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


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

                                                                                              0
                                                                                              Не конструктивно сразу откидывать приципы NPM:
                                                                                              image

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

                                                                                                        «перестаньте за меня думать» ©
                                                                                                  –1
                                                                                                  и снова javascript

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

                                                                                                  Самое читаемое