Все рушится

https://medium.com/@boneskull/things-fall-apart-d349c6e3ddba#.5tdaepg8c
  • Перевод
Давайте постараемся вместе уменьшить фрагментацию в мире JavaScript. Недавно, после анонса Yarn (пакетный менеджер для node.js от facebook прим. пер.), некоторые в JavaScript сообществе раскритиковали Facebook и проект в целом.

Существует тенденция для компаний или индивидумов форкать или пересоздавать OSS проекты, вместо работы над существующими в сообществе. Это случается по многим причинам, но это случается чаще чем нужно. Это объясняет, почему появился Yarn.

Панки живы!


По существу нет ничего плохого в DIY(«сделай это сам» прим. пер.) в OSS. Для разрабтчиков — это хороший способ узнать или показать на что ты способен. Пока у тебя нет фан-клуба, это капля в море.

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

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

Благими намерениями вымощена...


Если случается, что OSS проект X может в некоторых сценариях работать для компании, она попробует его использовать.

Но возможно, что она не достаточно хорошо изучила его, или изменились потребности, или поменялась сфера, или баг X все никак не пофиксят или миллион причин. Вместо сотрудничества, компания берет и пишет свою реализацию.

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

Бизнес любит и соглашается с идеей, что он «может возвращать» сообществу открыв исходники своего нового проекта! Разработчикам в компании это тоже нравится потому, что они пишут код по своим стандартам и практикам. Они больше не зависят от прихотей и временных рамок кого либо еще.

Более внимательный бизнес, сделает более добросовестное решение и вернет вклад в проект X. Пока код вливается в разумное время, все счастливы. Но если PR висит слишком долго или мейнтейнеры не согласны с решением и отклонили запрос, сотрудничество может закончится.

Что выльется в новый проект Z, который приведет к фрагметации на нескольких уровнях:

  • Сообщество. Из-за разделения, некоторые пользователи могут переметнуться к Z. Может Z подходит им больше, или они верят, что Z будет развиваться быстрее, или потому что, оно новое и блестит. Вклад в X может снизиться.

  • Усилия. Пользователи теперь будут контрибьютить в Z вместо вклада в проект X. Паритет по фичам или совместимости дублирует усилия.

  • Экосистема. Проект X хорошо распространен и у него есть плагины, и он предоставляет интеграцию с другими инструментами. Эти инструменты в экосистеме X могут быть или не быть совместимы с Z.

Индивидумы, бизнес и мейнтейнеры проекта могли бы постараться для предотвращения потенциальной фрагментации. Мейнтейнеры слишком завязаны или часто не понимают, что реально нужно пользователм, или у них другая мотивация. Компании думают, что они встречаются с «уникальными проблемами» чаще чем есть на самом деле.

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

Одинаковые, но разные


Когда я пытался использовать альтернативы npm cli, у меня просто сломались пакеты. Они сломались, поскольку ожидали, что будут установлены через npm cli. Не слишком очевидно, но все дело в lifecycle scripts и том как cli по особому обрабатывает симлинки директорий.

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

Не стоит ожидать, что альтернативы npm cli обеспечивают 100% совместимость с текущей экосистемой. Если бы они делали все тоже, что и npm cli, все бы прекратили пользоваться npm cli, включая сам npm.

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

Не так легко быть зеленым


Новенькие в node.js и JS сообществе столкнуться с еще одним выбором, какой инструмент использовать. Для них будет не понятно, почему npm не работает с этой библиотекой, которая была написана с использованием альтернативного cli. Или, почему альтернативный cli не работает с этой библиотекой, ожидающей npm.

Не смотря на все усилия и внимание вложенные в Yarn, он не сможет покрыть все случаи, не каждый будет ожидать 100% совместимости. Ветеран JavaScript экосистемы сможет найти обходные пути, но новичок нет.

Перемножаем матрицу сборки


Ты майнтейнер проекта. Однажды ты получаешь сообщение об ошибке от пользователя:

хей, этот пакет не работает с quuxbaz, новый npm клиент, добавьте поддержку плиз.

Забудь, что ты потратил прошлую неделю на исправление поддержки Windows. Теперь тебе нужно беспокоится о поддержке quuxbaz на Windows.

Ты можешь увидеть, как быстро растет эта проблема. Если ты уже поддерживаешь три (3) версии node.js на Linux, Windows и MacOS (9), то твоя матрица удваивается до восемнадцати (18), если учитывать, что quuxbaz работает на этих девяти конфигурациях. А может и не работает, так что забудь о тех странных багах над которыми ты работал, это на самом деле проблема с node.js 4.x под MacOS используя quuxbaz.

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

Более конкретный пример: когда появился Browserify, многие пакеты на node.js магическим образом заработали в браузере. Остальные оказались сломаны. Некоторые поправили этот «баг», другие нет. Время прошло и теперь Browserify работает вроде нормально, но не с Webpack. А потом ломается в каком то браузере, или electron, или телефоне или тостере и тд.

Как нам избежать таких проблем?

Командная работа!


Несмотря на причины почему мы здесь, мы все вместе.

Для пользователей


Как потребитель Node.js модулей, ты можешь помочь мейнтейнеру проекта, отправляя более детальные баг репорты, и/или код который исправляет эти баги. Если ты запостил баг, следи за его исправлением. Если ты законтрибьютил код, пожалуйста, помогай его поддерживать. Последняя часть, особенно важная.

Мейнтейнеры


Как мейнтейнер, будь открытым для новых идей и перспектив. Если ты выложил что-то на Github, ты должен ожидать, что кто-то будет это использовать, не так как ты это предполагаешь. Ты будешь удивлен как много разногласий решает «оставить это за флагом».

Бизнес


Для бизнеса — и специально для R&D команд — если проект имеет активное сообщество, присоединяйтесь. Может оказаться, что другой пользователь хочет такую же фичу что и вы. Может вы можете поработать над ней вместе, как например команда Yarn.

Команда Yarn


Ребята, вы приложили невероятные усилия. Наверное существует какое то недопонимание вокруг существования проекта.

Пожалуйста помогите понять сообществу, и особенно новичкам:

  • Что такое Yarn и для чего он?
  • Почему именно он?
  • Что можно ожидать от работы с ним?

Если я завтра увижу новое ишью «не работает с Yarn», хотя я не ожидаю что увижу, я бы хотел вики или документацию с описанием общих проблем, решений и известных несовместимостей, частые ошибки пользователей и тд.

И если вам не сложно, пожалуйста держите 100% совместимость с npm за флагом, спасибо.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 76
  • +7
    самая очевидная фича, которой годами не было в npm — это lock-файл. Нет lock-файла — нет фиксирования версий. Нет фиксирования версий — нет одинакового окружения у разработчиков, тестировщиков, деплойщиков. Нет одинакового окружения — дистрибьютим зависимости внутри проекта после установки через git.

    Почему эта фича не была добавлена? Наверняка обсуждения уже были, есть сторонние расширения, но нет из коробки. Если ответом было «by design», то очевидно, что единственный вариант — создание форка.
    • +8
      Вы про это https://docs.npmjs.com/cli/shrinkwrap?
      • 0
        да, похоже на то. тогда был не прав насчет этой фичи.
        • +1

          оно все равно какое-то кривое. нет той легкости использования, как у, к примеру, Bundler'a

          • +1

            Какое-то время назад он фиксировал версии не во всех случаях и некоторые вещи так же ломались. До bundler'а сильно не дотягивает(

          • 0
            дистрибьютим зависимости внутри проекта после установки через git.

            И что вы этом плохого? Ну кроме того, что "мне не нравится, что в моём репозитории лежит копия чужого кода".

            • +1

              Репозиторий распухает от такого. Недавно в чате ru.SO участник жаловался на медленную работу с полуторагигабайтным репозиторием...

              • 0
                и это истинная правда — у меня гигабайтный репо на текущем проекте.
                • 0

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

                  • +1

                    В любом случае, исключение чужого кода из репозитория спасает от обеих проблем.

                    • –3

                      А хранение кода в репозитории спасает от проблем по серьёзнее. Например, от вариативности кода в зависимости от инсталляции. При этом делает это гораздо надёжнее, чем lock-файл.

                      • +3
                        Maven смотрит на ваш комментарий со скепсисом…
                • +5
                  я хочу использовать систему контроля версий для контроля версий своего кода. чужой код я установлю инструментом для этого предназаченным.
                  Зачем мне хранить в git зависимости, если я знаю, что введя команду npm install получу идентичное окружение? особенно учитывая, что на маленьком проекте node_modules будет превышать размер собственного кода в разы. Пример: установил create-react-app — 80 мб зависимостей, а собственно мой код не весит и 100 кб.
                  • –7
                    я хочу использовать систему контроля версий для контроля версий своего кода.

                    Сторонний код — такая же часть вашего приложения, как и ваш код. Вы видимо не застали такие эпики как dll-hell, rpm-hell, jar-hell и прочие dependency-hell?


                    Зачем мне хранить в git зависимости, если я знаю, что введя команду npm install получу идентичное окружение?

                    NPM доступен 24/7, пакеты никогда не удаляются, исходники без изменения версии никогда не меняются, бинарные модули не зависят от окружения, где собираются. Классно у вас там, наверно.


                    Пример: установил create-react-app — 80 мб зависимостей, а собственно мой код не весит и 100 кб.

                    Хороший повод не использовать create-react-app и тому подобные монструозные тулзы, которые ставятся по 5 минут, а делают всего ничего.

                    • +6
                      Сторонний код — такая же часть вашего приложения, как и ваш код.

                      да, но отличие в слове «сторонний» — я могу его получить со стороны другим способом, и то, что он часть моего проекта не есть аргумент в сторону хранения в гите

                      NPM доступен 24/7, пакеты никогда не удаляются, исходники без изменения версии никогда не меняются, бинарные модули не зависят от окружения, где собираются. Классно у вас там, наверно.

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

                      Хороший повод не использовать create-react-app и тому подобные монструозные тулзы, которые ставятся по 5 минут, а делают всего ничего.
                      это не монструозная тулза, а стандартный набор либ фронтендера на js. Сам я не фронтендер, и меня вполне устраивает подождать 2 минуты и приступить к написанию кода вместо компилирования кусочков знаний из статей в интернете
                      • –2

                        Можете до поры до времени. А потом случается казус и уже не можете.


                        Вы пропустили эпичный эпик с left-pad?


                        Вас обманули, это ни разу не стандартный набор. В js вообще мало чего стандартного. Я уверен полезной функциональности там на мегабайт максимум.

                        • +4
                          Вы пропустили эпичный эпик с left-pad?

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

                          Вас обманули, это ни разу не стандартный набор. В js вообще мало чего стандартного. Я уверен полезной функциональности там на мегабайт максимум.

                          отставьте менторский тон. Я хоть и не фронтендер, но в js-инфраструктуре разбираюсь прекрасно.
                          • –2

                            И как же он там предусмотрен?


                            Вы прекрасно разбираетесь лишь в текущем тренде. Это вершина айсберга.

                          • 0
                            Парсер JS, сборщик JS, компилятор JS, транслятор JS, полифиллы JS, оптимизация JS, минификация JS, украшение JS, сжатие JS
                            Логирование, работа с сетью, реализация Virtual DOM, библиотека функций Lodas
                            И еще куча всего, что нужно для работы тех или иных пакетов
                            Если готов написать свой сборщик JS с HMR и CSS, рад буду использовать
                            А еще запилил свой аналог React
                            С Redux можешь не заморачиваться, он мало весит
                            • –2
                              Парсер JS

                              Сам по себе парсер бесполезен.


                              сборщик JS, Если готов написать свой сборщик JS с HMR и CSS, рад буду использовать

                              Сборщик JS и CSS. HMR вам не понадобится, ибо приложение загружается мгновенно.


                              компилятор JS, транслятор JS,

                              Транспилятор TS.


                              полифиллы JS

                              Лучше понифилы. Грамотные реализации много не едят.


                              оптимизация JS, минификация JS, сжатие JS

                              gzip с этим справляется эффективней.


                              реализация Virtual DOM, А еще запилил свой аналог React

                              Нафига? Есть подходы по интересней, чем перегенерировать дерево на каждый чих.


                              библиотека функций Lodas

                              Вы бы ещё jQuery вспомнили.


                              Логирование, работа с сетью

                              Логировнаие, работа с сетью и всё такое.


                              С Redux можешь не заморачиваться, он мало весит

                              Спасибо, ваше высочество :-)

                              • +2

                                толсто.


                                Вы пропустили эпичный эпик с left-pad?

                                нет, как и npm, больше такого не повторится с модулями старше 24 часов.


                                HMR вам не понадобится, ибо приложение загружается мгновенно.

                                HMR нужен не для быстрого перезапуска, а сохранения текущего стейта приложения. Особенно полезно при отладке большой формы, например.


                                gzip с этим справляется эффективней.

                                любая минификация перед сжатием, делает сжатый бандл меньше. А переодически и код ускоряет.


                                Вы бы ещё jQuery вспомнили.

                                иногда и jquery нужен, если маленький проектик на вечер и сроком жизни пару недель. А lodash все еще must have, особенно fp часть божественна.

                                • –2
                                  толсто

                                  Кто первый обвинит оппонента в толстоте — тот не тролль.


                                  нет, как и npm, больше такого не повторится с модулями старше 24 часов.

                                  Не повторится потому, что ___.


                                  HMR нужен не для быстрого перезапуска, а сохранения текущего стейта приложения.

                                  Для этого есть sessionStorage.


                                  Особенно полезно при отладке большой формы, например.

                                  А формы тем более по умолчанию должны выдерживать перезагрузку.


                                  любая минификация перед сжатием, делает сжатый бандл меньше.

                                  Ага, и стектрейсы с продакшена приходят тоже сильно короче. Профит от минификации минимален, а проблем вызывает море:


                                  1. Долгая сборка, из-за чего её отключают при разработке, из-за чего разработчик тестирует не в точности тот же код, что будет крутиться на проде.
                                  2. Без сорсмапов не разобраться что там происходит. А сорсмапы нужной версии не всегда есть или хотя бы легкодоступны.
                                  3. Отладчику даже с сорсмапами периодически сносит крышу.

                                  иногда и jquery нужен, если маленький проектик на вечер и сроком жизни пару недель.

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


                                  А lodash все еще must have, особенно fp часть божественна.

                                  Особенно божественно заниматься отладкой fp части, ага. Исполнение по шагам, условные точки останова, просмотр результата выполнения функции — всё это так удобно с так называемым fp, который к собственно функциональному программированию не имеет никакого отношения.

                                  • 0
                                    Руки просто у вас кривые, раз не осиливаете современный инструментарий JS
                                    • 0

                                      Поможете мне их выпрямить?

                                      • –2
                                        У него руки не кривые. В современном JS нечего осиливать. Перечислите пожалуйста десяток современных JS инструментов, чтобы был какой-то ориентир.
                          • +4
                            Вы видимо не застали такие эпики как dll-hell, rpm-hell, jar-hell и прочие dependency-hell?

                            Современные инструменты существуют, чтобы решать старые проблемы. Иначе зачем эти новые инструменты нужны?

                            • 0
                              Сторонний код — такая же часть вашего приложения, как и ваш код. Вы видимо не застали такие эпики как dll-hell, rpm-hell, jar-hell и прочие dependency-hell?
                              Для всех перечисленных проблем есть нормальные решения. Взять хотя бы тот же Maven для Java.
                              • 0

                                Почти всегда работают, но иногда приходится использовать maven-shade-plugin или шейдить нужные куски руками. Но с maven'ом куда лучше чем без него ,)

                          • 0
                            А как тогда быть с node-аддонами на сях?
                            • 0

                              на самом деле все ок и с таким подходом. есть npm rebuild.
                              Правда бывает, что бинарники под разные OS выкачиваются postinstall, так делает electron и nodegit, навскидку. Тут уже ничего не поделаешь с любым подходом.

                              • 0
                                Именно с этим мы и столкнулись, когда несколько лет назад пытались хранить все зависимости в гите.
                              • +1

                                Это очень плохо. Правда.


                                • Не все зависимости могут быть перенесены простым копированием папки node_modules, так как многие написаны например на С++, и требуют сборки. При этом, у разных разработчиков может быть не совместимое по ABI окружение или просто разные ОС.
                                • Многие пакеты при установке требуют выполнения lifecycle scripts про которые упоминается в статье. Естественно при копировании node_modules они не будут выполненны.
                                • package.json больше не является источником информации о действительно нужных зависимостях, все решает содержимое папки
                                • Учитывая все вышеперечисленное, а текже применяемую в npm методику дедупликации пакетов (когда вместо копирования одного и тогоже пакета, который является не прямой зависимостью он ложится в корень node_modules один раз) разрешение конфликтов в случае когда в одной версии модуль a удален, в другой модуль b обновлен или перемещен будет весьма веселым занятием
                                • Уже упомянутое распухание репозитория

                                Все вышеперечисленное актуально не только для ноды, проблема стара как мир, и правильным перешением является lock-файл.

                                • –2
                                  Не все зависимости могут быть перенесены простым копированием папки node_modules, так как многие написаны например на С++, и требуют сборки.

                                  Большинство модулей поставляются с пребилдами под популярные оси/архитектуры.


                                  Многие пакеты при установке требуют выполнения lifecycle scripts про которые упоминается в статье.

                                  Например? Вообще, на мой взгляд, это дурная практика.


                                  package.json больше не является источником информации о действительно нужных зависимостях, все решает содержимое папки

                                  Либо содержимое shrinkwrap.json. Кстати, типичная ситуация — кто-нибудь добавил модуль себе локально, но забыл добавить его в package.json — привет, падение в случайный момент.


                                  Учитывая все вышеперечисленное, а текже применяемую в npm методику дедупликации пакетов

                                  Это изначально была фиговая идея — ставить модули внутри, а не на одном уровне. Да, разные версии модулей тоже можно ставить на одном уровне. Пример, адекватной реализации — DUB.


                                  в другой модуль b обновлен или перемещен будет весьма веселым занятием

                                  Всё просто — разрешаем в любую сторону, а потом npm install.

                                  • 0

                                    Те самые пребилды выкачиваются обычно через lifecycle scripts. Можно конечно надеятся что они сложат их в node_modules, но как по мне — очень не надежно.
                                    Примеры: ngrok, phantomjs, electron
                                    А вот пример аддона для ноды, который нужно скомпилить при установке: node-proxy
                                    Конечно, я согласен что стоит по возможности обходится без использования lifecycle scripts где это возможно, но они присутствуют в любом пакетном менеджере вплоть до apt. А вот действиительно плохой практикой является нарушение инкапсуляции работы пакетного менеджера.
                                    Если ее не нарушать — все равно в какие папки и в сколько копий он кладет модули и выкачивает зависимости.
                                    По поводу разрешения конфликтов я не понял. Т.е все равно, нужно хранить в актуальном виде package.json и npm-shrinkwrap.json, что осложеннно тем, что обычно при таком подходе они не используются, НО, если возник конфликт — все что до этого так берегли полетит в топку, и именно они будут определять что в итоге окажеться закоммичено с node_modules в репозитории?

                              • 0
                                самая очевидная фича, которой годами не было в npm — это lock-файл. Нет lock-файла — нет фиксирования версий.

                                Так в package.json ведь указываются версии зависимостей. Или я чего-то не так понимаю?

                                • +2

                                  В npm существует возможность указывать не конкретную версию — а диапазон (т.н. "мягкие" зависимости). И если для своего проекта достаточно эту возможность не использовать — то что делать когда эта возможность используется сторонними пакетами?

                                  • +1

                                    То есть lock файл нужен, чтобы фиксировать версии всех зависимостей, а не только тех, которые присуствуют в проекте явно?

                                    • +4

                                      Да, всё так. Lock-файл (эта идея пришла, кажется, из Bundler'а и с огромным успехом сейчас используется в Rust'овом Cargo) фиксирует версии всех зависимостей, транзитивных в том числе. Кажется, ещё yarn решает проблему с недетерминированным порядком установки пакетов и их расположению в файловой системе, которая есть у npm.

                                  • +1
                                    >= 2 у одного разработчика может дать 2.0.1, а на следующий день у другого разработчика 2.1.0, что может повлечь за собой изменение и других версий других либ, а также поломку кода.
                                    • 0
                                      Если соблюдается semver, то версии 2.X.X не содержат braking changes, а значит поломки кода не будет. Да и нотации вида ">= 2" лучше использовать только в peerDependencies. В целом, все проблемы возникают только из-за не следования рекомендациям и не соблюдения общепринятых правил.
                                      • +3
                                        Если соблюдается semver, то версии 2.X.X не содержат braking changes

                                        а) помимо соблюдения семвера нужно, чтобы новые куски кода не ломали старый по недосмотру — это бывает, но в идеальном мире
                                        б) >=2 — это все же и 3.* тоже
                                        в) все-таки надежда на соблюдение сторонними разработчиками правил — это непозволительная роскошь для продакшна
                                • 0
                                  А что за аллегория такая «Это сродни пушечному ядру». Что имеется в виду?
                                  • 0
                                    мощь и разрушительность — огромный ресурс большой компании во благо себе, но во вред сообществу
                                    • +1
                                      Слон в посудной лавке.
                                      • 0
                                        Неудачный (буквальный) перевод.
                                      • –1
                                        Yarn использует пакеты из npm registry, а значит Вы можете пользоваться npm и дальше. Не вижу в этом никакой проблемы.
                                        • +3

                                          Комментарии сообщества в духе "надо было в npm законтрибьютить" забавляют. В OSS никто никому ничего не должен, а конкуренция(форки, аналоги) в итоге, только улучшает конечный продукт для пользователя.
                                          Но странно, что yarn выложили, а registry — нет.

                                          • +1
                                            Вы тоже заметили, что автор, видимо, не сторонник конкуренции?

                                            Старый Добрый Монополист в стабильных условиях всегда лучше конкуренции. Вот, был один npm и было нормально (но не супер, ведь монополисты, они такие). По идее, монополию должна сменять конкуренция более технологичных продуктов в ситуации отсталости монополиста и/или динамичной смены условий на рынке.

                                            И при этом почти всегда конкуренты новой формации видятся более слабыми и некрутыми. Может, yarn это будущее, а противники yarn превращаются в луддитов с каждым новым комментом.

                                            пикрелейтед
                                            • 0

                                              Картинка с эволюцией прекрасна, единственный её недостаток это то, что на ней нарисовано то, чего никогда не было.

                                              • 0
                                                Не было «по форме» или «по существу»?
                                            • +1
                                              Всему есть своя мера.
                                              Одно дело, когда эти процессы идут годами-десятилетиями и совсем другое, когда каждые неск. месяцев нет-нет, да появится очередной «убийца php/npm/js».

                                              Это дезориентирует( особенно начинающих).
                                              Это приводит к дроблению сообщества и бесполезной трате его ресурсов на изобретение очередных велосипедов, абсолютное большинство из которых загнётся в грязи и тени.
                                              И, что самое главное — это приводит к увеличению расхода времени программиста на что угодно, кроме, собсно, разработки( чтение бесконечной документации очередного пупер-инструмента, попытки выяснить, как он * работает итд итп).

                                              Как итог, в большинстве своём, ничего кроме вреда, подобное не несёт.
                                              В конкуренции, как и во многом остальном, д.б мера, а не нескончаемый поток почти идентичных по своей сути продуктов, цвета уже не столь небесного/радужного, сколь жёлтого или, того хуже, коричневого…
                                              • +1

                                                Никто не призывает новичка использовать yarn. NPM освоит и хорошо.
                                                Тот факт, что каждый месяц что-то выходит — особенность области. Надо учиться различать перспективные новинки, от однодневок.
                                                А что по вашему делать, если npm устанавливает зависимости 5 минут, а yarn — 30сек?

                                                • 0
                                                  Если присмотреться к коду основных инструментов, которые использовались\используются в веб-разработке, то там везде торчат одни и те же имена. Yehuda Katz, Paul Irish, James Kyle, ну я только в топ контрибуторов Yarn посмотрел.
                                                  Мне кажется, что я слышал эти имена еще когда Руби и Рельсы были мейнстримом.
                                                  Складывается впечатление, что есть небольшое сообщество энтузиастов на зарплате, которое задает тон генеральной линии развития JS инфраструктуры. Как только им надоедает очередной фреймворк — они его забрасывают и начинают очень бурно создавать что-нибудь другое.
                                              • –5
                                                Так получается, когда код пишут не инженеры, а олимпиадники и математики. Хотя олимпиадники и математики должны быть на контракте и консультировать, максимум. Самый простой пример — Гугол. Конкуренцию которого выдерживают только Майкрософт и прочие big-4. Отсутствие потолка привело к гипер-росут Гугла и неконкурентноспособности Нокия, Опера, Яндекс и прочие. Закрытию десятков сервисов и превращения IT в какую-то дикую кашу с фреимворками на миллионы строк для создания простого веб-приложения.
                                                • +4
                                                  походу статья прошла мимо вас, а вы запостили заготовку под любую статью о мегакорпорациях
                                                • 0
                                                  JS сообщество недовольно новым пакетным менеджером? Взрослеют?))
                                                  • 0
                                                    Можно ли назвать взрослением точку зрения «у меня все работает, зачем они изобрели очередной велосипед»?
                                                    • 0
                                                      Обычно сообщество подхватывает каждый новый велосипед от фейсбука или гугла или еще от кого-то известного и сразу пытается затянуть в продакшн. Сразу появляется сотни статей на тему какой классный велосипед. И обычно мало кто думает «зачем еще один?», а вот конкретно в этом случае этот вопрос появился.

                                                      По-моему, когда в умах первая мысль «зачем еще один?», а не «вау! нужно перевести на новую технологию!» — это признак взросления.
                                                  • 0
                                                    Так нет никакой фрагментации. Yarn несовместим с npm только на клиентской стороне, да и то, частично. В остальном это всего лишь кеширующая прокся для уже существующего репозитория. Все, что вы публикуете в npm, доступно и в yarn (и наоборот, насколько я понимаю).
                                                    Это всего лишь еще один инструмент — хотите используйте, хотите — нет.
                                                    • 0
                                                      в общем это клиент к npm registry с сахарком
                                                    • +1
                                                      Автор так пишет, как будто npm – безупречный и лишённый изъянов продукт, а Facebook вот тут выпустил свою поделку на коленке – yarn – и теперь заставляет лично его ей пользоваться (к тому же, очевидно, угрожая смертью ему и его семье, судя по количеству ненависти и ксенофобии в статье).

                                                      Лично мне инициатива нравится, поскольку в при работе с npm иногда возникает великое большое множество проблем – низкая производительность, большой объём зависимостей на диске и т.д., и очевидно, что npm Inc часть этих проблем не решает, и если хотя бы некоторые из них будут качественно решены посредством yarn, это будет замечательно, а поддержка необходимых фичей вроде lifecycle scripts для более качественной совместимости с npm появится со временем, поскольку сообщество этого требует.

                                                      Если что, ни в кого ссаными тряпками кидаться не хотел, и всё написанное – лишь моё мнение, которое имеет право на жизнь так же, как и статья автора.
                                                      • 0

                                                        Нет у Yarn действительно важных фич, то чего действительно не хватает так это указания версии nodejs в package.json и соответственно работы приложения именно с этой версией вне зависимости от того что стоит непосредственно в окружении.

                                                        • 0

                                                          Как вы это себе представляете? Фиксация версии ноды — не задача пакетного менеджера.

                                                          • 0

                                                            На самом деле, это б-м реально.
                                                            Если загружать голые рантаймы ноды для каждого пользователя и производить запуск через прокси-executable. Пример — nvm, который просто скрипт.
                                                            Проблем тут две


                                                            1. Рантайм для самого yarn
                                                            2. Жёсткая обратная совместимость самого yarn.
                                                            • 0

                                                              Вы забыли третью проблему — что делать, если два разных пакета требуют разные версии рантайма?..

                                                              • +2
                                                                Ответ очевиден: выдавать сообщение о конфликте и прекращать работу.
                                                                • +1

                                                                  Для инструмента — да. Но что делать тому, кто эту радость будет запускать? :)

                                                                  • 0

                                                                    А представьте себе такую жизненную ситуацию, у вас есть сервер на котором работает жирный такой сервис на Nodejs, и ему года 3, и все эти годы никто в него не заглядывает а его разработчик давно уволился, и тут вам нужно задеплоить туда еще один сервис, естественно написанный на куда более свежей ноде, и вот проблема этот древний сервис не запускается на новой версии Nodejs. И решений сейчас тут только два и оба та еще "радость", это ковырять старый сервис решая проблемы совместимости или ковырять что-либо из контейнеризации типа Docker.

                                                                    • 0

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


                                                                      Если старый код настолько плох что даже я в нем не смогу разобраться — можно же просто поставить две ноды на сервер… Но вашу проблему я понял. Так вот, через фиксацию версии ноды она не решается.


                                                                      Потому что старый и новый код в любом случае придется запускать с разными рантаймами. А значит, они должны ставиться как дополнительные пакеты, а не быть атрибутом проекта.


                                                                      Пакеты же с дополнительными рантаймами можно создать и в рамках текущей функциональности npm. Кажется, я даже видел посвященный этому проект.


                                                                      Именно поэтому и я говорил что это не задача пакетного менеджера.

                                                                      • 0

                                                                        Мой опыт рефакторинга старого приложения под более свежую версию Nodejs был настолько неудачным, что у меня осталась психологическая травма. Возможно помните что ранняя версия express изначально хранила в себе большую часть модулей, а потом авторы решили вынести их по разным пакетам, и это была проблема только одного из множества пакетов изменивших API. Я отлично понимаю почему зафиксировать версию ноды для приложения проблематично при текущей архитектуре, но уверен что решение в рамках пакетного менеджера придумать возможно, пусть хоть он докер контейнеры разворачивает под капотом, хорошая практика оставить на усмотрение разработчика выбор — лишний оверхед или решать конфликты ручками.

                                                                        • 0

                                                                          Даже с докер-контейнерами не получится зафиксировать. Просто из-за постановки задачи. Вам нужны две разные ноды в одном проекте. А вы предлагаете оставить одно свойство для номера версии. Два разных значения в одно никак не залезут.


                                                                          Просто представьте как вы будете записывать желаемое в файле package.json.


                                                                          А то, что нужно вам, называется nvm

                                                                          • –2

                                                                            Да, действительно nvm exec 6.8.1 npm install & nvm exec appname решают проблему. Это действительно круто, 2 года назад когда я столкнулся с проблемой подобное решение если и было то не гуглилось. Спасибо за наводку. А давайте представим что Yarn красиво интегрировал в себя nvm, и умеет читать из package.json аттрибут "nodejs-version":"6.8.1". И теперь когда мы делаем yarn install, yarn сам скачает нам нужную версию ноды и npm, а yarn run будет у нас алиасом для nvm exec 6.8.1 appname, для зависимых пакетов их локальный атрибут "nodejs-version" будет игнорироваться. И в итоге мы получаем 1. Более user friendly управление версией ноды для проекта 2. можно глобально обновлять ноду и не боятся что остальные сервисы перестанут работать. Вполне достойная как по мне фича, что бы сделать еще один менеджер пакетов (сарказм)

                                                                      • 0

                                                                        В чем проблема скомпилировать две версии node.js?

                                                              • 0

                                                                Я как пользователь пакетного менеджера не должен себе ничего представлять. У меня тут рядом есть пакетный менеджер из другой оперы — leiningen, там можно указать версию интерпретатора, и могу сказать что это очень удобно. Почему бы мне не хотеть того же от npm или Yarn?

                                                                • 0
                                                                  он и не должен фиксировать. Он должен ругнуться, если текущая версия ноды не соответствует требуемой версии ноды зависимости, и соответственно эту зависимость не установить.
                                                                • 0

                                                                  Есть поле engines в package.json для этого ("engines": { "node": ">4" }) и флаг --engine-strict.

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