Давайте работать вместе, чтобы уменьшить влияние фрагментации JavaScript.

Вчера, после анонса Yarn, некоторые в сообществе JavaScript, включая меня, раскритиковали Facebook и проект. Комментарии, которые я делал (по поводу Ava и pnpm), были реакционными и написаны в спешке; в конечном итоге я был просто неправ.

Обычно я люблю подумать, прежде чем говорить. Когда я этого не делаю, это обычно происходит из-за того, что мои кнопки нажимаются на кнопки или нервничают. Теперь, когда я досчитал до десяти (10), я хотел бы поделиться своими мыслями.

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

Панки живы

В OSS нет ничего по сути плохого в DIY. Для разработчиков это может стать отличным способом узнать или показать, на что вы способны. Если у вас нет фан-клуба, это капля в море.

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

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

Вымощены добрыми намерениями

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

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

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

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

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

Оба вышеперечисленного, в результате чего создается новый проект Z, могут вызвать фрагментацию на нескольких уровнях:

  • Сообщество. Разделение может заставить других пользователей покинуть корабль за Z. Может быть, Z лучше подходит для их варианта использования, или они считают, что Z будет двигаться быстрее, или просто потому, что он блестящий. Публикации в X могут быть отклонены.
  • Усилия. Ранее пользователи теперь будут участвовать в Z вместо - но не в дополнение к - проекту. X. Поддержание паритета или совместимости функций приведет к дублированию усилий.
  • Экосистема. Если X - широко используемый инструмент, он может иметь плагины и обеспечивать взаимодействие с другими инструментами. Эти существующие проекты в экосистеме X могут быть совместимы или несовместимы с Z.

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

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

То же самое, за исключением разных

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

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

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

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

Непросто быть зеленым

Новички в сообществах Node.js и JS столкнутся с еще одним выбором того, какой инструмент использовать. Они удивятся, почему npm не работает с библиотекой, написанной кем-то с использованием альтернативного интерфейса командной строки. Или, наоборот, почему альтернативный интерфейс командной строки не работает с библиотекой, написанной с ожиданием 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 (глагол). А потом не работает в браузере без головы. Или Электрон, или телефон, или тостер и т. Д.

Как мы можем решить эти проблемы?

Работа в команде!

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

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

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

Сопровождающие

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

Biz

Для предприятий - и особенно для команд НИОКР - если у проекта есть активное сообщество, присоединяйтесь к нему. Вы можете узнать, что другому пользователю нужна та же отсутствующая функция. Может быть, вы сможете поработать над этим вместе, как Team Yarn.

Пряжа Команда

Команда, это выдающееся усилие. Могут существовать некоторые давние недоразумения в отношении существования проекта, а не его управления.

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

  • Для чего и для кого предназначена Пряжа?
  • Для чего это и кому не?
  • С чем я могу ожидать, что он будет работать?

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

И если вы чувствуете себя милосердным, пожалуйста, отметьте 100% совместимость с npm, спасибо.