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, где можно ознакомиться с проектом и принять участие в разработке.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 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.

                                                                                        • UFO just landed and posted this here
                                                                                            +3

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


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


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

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

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

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


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

                                                                                              • UFO just landed and posted this here
                                                                                                  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

                                                                                                    Only users with full accounts can post comments. Log in, please.