Ещё один однострочный пакет npm сломал экосистему JavaScript
В субботу обновление маленькой библиотеки is-promise вызвало переполох в значительной части экосистемы JavaScript. Зависимости от сломанной библиотеки встроены в 3,4 миллиона проектов. Это уже второй раз, когда крошечный проект JavaScript вызывает проблемы такого масштаба.
Библиотека is-promise состоит из двух строк кода, а разработчики могут использовать её в своих проектах с помощью однострочного вызова.
declare function isPromise(obj: Promise | S): obj is Promise;
export default isPromise;
Предназначение библиотеки состоит в проверке, что JavaScript-объект является типом Promise, то есть представляет собой конечное завершение асинхронной операции и её результирующее значение.
При использовании в продакшне функция isPromise возвращает логический результат yes или no.
Хотя это всего две строки кода, выполняющие базовую проверку, библиотека is-promise является одним из самых популярных на сегодняшний день пакетов JavaScript npm. По данным GitHub, библиотека является частью более чем 3 431 756 проектов и используется в качестве зависимостей 767 другими библиотеками JavaScript.
В минувшие выходные библиотеку обновили, чтобы реализовать поддержку работы в качестве ES-модуля — стандартизированной модульной системы JavaScript.
Но оказалось, что is-promise версии 2.2.0 не соответствует стандартам модуля ES. Как только вышло обновление, проекты, которые использовали is-promise внутри цепочки сборки, начали выдавать ошибку при сборке из-за неправильной поддержки ES-модуля (1, 2, 3, 4, 5, 6, 7, 8, 9, 10).
Сбой библиотеки мгновенно отразился на множестве проектов: от проприетарных проектов с закрытой кодовой базой до некоторых крупнейших опенсорсных проектов экосистемы JavaScript.
Ошибка распространилась, в том числе, на следующие проекты: приложение Create React от Facebook (стандартный шаблон для создания приложений React), фреймворки Angular.js, Serverless (AWS), Firebasse-tools, Nuxt.js, AVA и многие другие.
So this just happened.
Is-Promise just made a little change and it broke multiple packages.So far as I’ve read its broken Firebase-tools, angular cli, aws serveless cli, create react app, possibly more.https://t.co/3ZZofevWNR
— Preet™ (@TmPreet) April 25, 2020
Ошибка не привела к сбою работающих проектоа, поэтому не произошло никаких фактических простоев, но она мешала разработчикам компилировать новые версии своих проектов.
Мейнтейнеры is-promise оперативно выпустили обновление, но оно не смогло исправить проблему. В конечном итоге пришлось отказаться от поддержки модулей ES в следующей версии 2.2.2, выпущенной через несколько часов после того, как начались массовые сообщения об ошибках из зависимых проектов.
Это второй инцидент, когда крошечная библиотека JavaScript вызвала проблемы во всей экосистеме JavaScript. Нечто подобное произошло в марте 2016 года, когда автор библиотеки left-pad (из 17 строк кода) решил ни с того ни с сего отозвать свою библиотеку, чуть не сломав подобным образом тысячи проектов. Код left-pad просто заполняет левую часть строки нулями или пробелами. Несмотря на простоту модуля, в тысячах приложений менеджер NPM не смог установить зависимости между пакетами. Чтобы в экстренном порядке исправить ситуацию, технический директор и сооснователь NPM Лори Восс (Laurie Voss) пошёл беспрецедентный шаг (так он назвал его в твиттере) и, «учитывая серьёзность и распространённость проблемы», отменил отзыв модуля. Была опубликована старая версия модуля, аналогичная последней.
В инциденте с is-promise отзыва модуля не произошло, но он опять вызвал вопросы и породил обсуждение — действительно ли в экосистеме JavaScript необходимы однострочные библиотеки.
Приводятся те же аргументы, что и в в 2016 году. Одни говорят, что модульность зашла слишком далеко, когда разработчики импортируют библиотеки для самых тривиальных операций.
Вот что по этому поводу считает Дэвид Хейни (David Haney), ведущий инженер-программист Stack Overflow:
«Создаётся впечатление, что участники экосистемы NPM взрастили фетиш микропакетов. Вместо того, чтобы написать любую функцию или код, они как будто предпочитают установить зависимость на что-то, написанное кем-то другим. Мне кажется, что вся работа программиста в экосистеме NPM сводится к написанию как можно меньшего количества кода, чтобы связать вместе существующие библиотеки, вместо создания чего-то нового, функционирующего уникальным образом, для личных или коммерческих нужд.Нет абсолютно никакой гарантии, что написанное кем-то ещё правильно или вообще будет нормально работать. Даже если всё корректно, это ли оптимальный способ решения проблемы? По крайней мере, когда вы пишете код сами, вы можете легко изменить его, исправить баги и повысить эффективность. Не должно быть особенно много багов в функции из 1 строчки.
Во-вторых, даже если логика в пакете правильная, меня поражает тот факт, что разработчики устанавливают зависимости на однострочные функции, которые должны сами уметь писать с закрытыми глазами. Если ты не можешь написать функцию left-pad, is-positive-integer или isArray за пять минут (включая время на поиск в Google), то ты вообще не умеешь программировать.
В конце концов, связывание вместе разных API не является программированием. Это какая-то сумасшедшая форма хакинга зависимостей, которая включает в себя облака и перегруженность кодом и сложностями, реально не нужными.
Пожалуйста, ради любви ко всему, что представляет собой программирование, самостоятельно напишите проклятые базовые функции. Ставить зависимости на однострочные пакеты — это вообще рехнуться».
Другие утверждают, что модульность элементов необходима, поскольку тогда каждая простая задача управляется внутри одного модуля, и ею не занимаются тысячи разработчиков, каждый по-разному в своих собственных проектах.
