Давайте постараемся вместе уменьшить фрагментацию в мире JavaScript. Недавно, после анонса Yarn (пакетный менеджер для node.js от facebook прим. пер.), некоторые в JavaScript сообществе раскритиковали Facebook и проект в целом.
Существует тенденция для компаний или индивидумов форкать или пересоздавать OSS проекты, вместо работы над существующими в сообществе. Это случается по многим причинам, но это случается чаще чем нужно. Это объясняет, почему появился Yarn.
По существу нет ничего плохого в DIY(«сделай это сам» прим. пер.) в OSS. Для разрабтчиков — это хороший способ узнать или показать на что ты способен. Пока у тебя нет фан-клуба, это капля в море.
Но если это делает бизнес, который может выделить ресурсы и таланты для проекта, с нужными связями и маркетингом — это сродни пушечному ядру. И действует исключительно в своих интересах, что может причинить вред OSS сообществу.
Я хочу рассказать почему компания может прийти к такому решению (см. также: фатальный недостаток), и какие от этого могут быть последствия.
Если случается, что OSS проект X может в некоторых сценариях работать для компании, она попробует его использовать.
Но возможно, что она не достаточно хорошо изучила его, или изменились потребности, или поменялась сфера, или баг X все никак не пофиксят или миллион причин. Вместо сотрудничества, компания берет и пишет свою реализацию.
Разработчики в компании понимают, что дешевле будет сделать все самим. Я знаю это, потому что, сам так делал. И в этом есть какой то смысл.
Бизнес любит и соглашается с идеей, что он «может возвращать» сообществу открыв исходники своего нового проекта! Разработчикам в компании это тоже нравится потому, что они пишут код по своим стандартам и практикам. Они больше не зависят от прихотей и временных рамок кого либо еще.
Более внимательный бизнес, сделает более добросовестное решение и вернет вклад в проект X. Пока код вливается в разумное время, все счастливы. Но если PR висит слишком долго или мейнтейнеры не согласны с решением и отклонили запрос, сотрудничество может закончится.
Что выльется в новый проект 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 экосистемы сможет найти обходные пути, но новичок нет.
Ты майнтейнер проекта. Однажды ты получаешь сообщение об ошибке от пользователя:
Забудь, что ты потратил прошлую неделю на исправление поддержки 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», хотя я не ожидаю что увижу, я бы хотел вики или документацию с описанием общих проблем, решений и известных несовместимостей, частые ошибки пользователей и тд.
И если вам не сложно, пожалуйста держите 100% совместимость с npm за флагом, спасибо.
Существует тенденция для компаний или индивидумов форкать или пересоздавать 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 за флагом, спасибо.
