[Перевод] Кто на самом деле пользуется is-odd и is-even?
Разработчики любят подшучивать над раздуванием зависимостей Javascript (и вполне имеют на это право, учитывая историю пакетов наподобие left-pad); при этом часто упоминаются пакеты is-even и is-odd. Поэтому я заинтересовался, кто же на самом деле их использует?
Что такое is-even и is-odd?
В большинстве приложений для выполнения часто встречающихся задач используются общие пакеты, чтобы разработчикам не приходилось переписывать заново код, уже написанный кем-то другим. Такие пакеты часто распространяются через менеджер пакетов (в случае Javascript это npm — node package manager).
is-even и is-odd — это пакеты npm, проверяющие число на чётность или нечётность. Если это всё, что вы о них знаете, то их существование может показаться неоправданным, ведь эту задачу можно решить одной строкой кода: n % 2 === 0. Однако Javascript без проблем позволяет проверять чётность или нечётность строк; в этом случае возникает вопрос, возвращает ли код false из-за какой-то ошибки или потому, что число действительно нечётное.
is-even и is-odd берут на себя эту проблему, выполняя дополнительную проверку ошибок. В частности:
Преобразуя
nв положительное числоПроверяя, действительно ли
nчислоИ находится ли
nв пределах «Safe Integer», потому что в противном случае окажется, что12345678978901233 % 2 === 0возвращает true, хотя число заканчивается на 3.
Кто пользуется is-even и is-odd?
Учитывая популярность шутки, я ожидал встретить их использование в куче пакетов и думал, что написать этот раздел будет очень просто. Однако я приятно удивился, практически не обнаружив их использования. Первым делом я убедился, что сам не использую эти пакеты, поискав их в node_modules проектов, над которыми работаю. Их там не было.
Затем я выполнил проверку через npmgraph. Оказалось, что он показывает пакеты, которые используются is-odd, но не наоборот. Любопытно (хотя, вероятно, это и не должно было меня удивлять), что автор is-even и is-odd сам активно пользуется своими пакетами. Если вы нажмёте на несколько случайных пакетов на странице по ссылке выше, то есть высокая вероятность, что найдёте там имя jonschlinkert.
[Забавный факт: за восемь часов до начала моего исследования владелец запушил регрессию, поломавшую веб-сайт. Мне пришлось создать пул-реквест и надеяться, что он проверит свою почту в субботу в канун Нового года… Веб-сайт оказался не особо полезным для моей задачи, но было бы забавно, если бы моё исследование закончилось в самом начале, как будто некие высшие силы повелели мне прекратить и не идти дальше.]
Затем я подошёл к этой проблеме с двух сторон:
Во-первых, проведя обширный поиск кода на github, чтобы проверить, какие пакеты зависят от них. Поиск всех версий is-odd возвращает 36 тысяч результатов, проверить которые самостоятельно я вряд ли смогу. Ограничившись последней версией, выпущенной больше шести лет назад (3.0.1), я получил всего 98 результатов; все они были лишь маленькими личными проектами. Недостаток такого подхода в том, что я ограничиваю поиски только Github, только последними версиями репозиториев, только репозиториями, которые коммитят файл lock, и только теми, которые используют версию v3.0.1. Плюс в том, что мне не пришлось вручную проверять все 36 тысяч репозиториев.
Также я попробовал поискать репозитории в фреймворках популярных организаций наподобие React и Vuejs. Хотя я и нашёл одну ссылку на пакет в Vue, это транзитивная зависимость и старая версия nyc в выведенном из эксплуатации репозитории примера того, как выполнять юнит-тестирование. Поэтому я с радостью могу сказать, что React, Next, Vue, Nuxt и Svelte в безопасности. Но в то же время я понял, что если действительно хочет быть уверенным, то необходимо проверять самостоятельно, ведь со старыми версиями и малоизвестными пакетами, не так аккуратно обращающимися со своими зависимостями, может произойти что угодно.
Большинство скачиваний связано со старой версией micromatch, тоже написанной jonschlinkert.
Эти методики неидеальны, но я могу вполне уверенно сказать, что если вы пользуетесь чем-то, написанным за последние три года, то, вероятно, у вас нет зависимости от какого-то из этих пакетов. Если бы я сильно хотел разобраться, где используется is-odd, то, скорее всего, мне пришлось бы скачать список всех пакетов с npm и их зависимостей, а затем создать граф зависимостей из двух миллионов узлов. Если у вас появится более умная идея, напишите мне, но пока это всё равно проект на будущее.
Зачем появились is-even и is-odd?
По словам автора, он опубликовал их в 2014 году, когда сам ещё учился кодить. Я не думаю, что когда я начал писать код, мне пришло бы в голову опубликовать что-то в международный централизованный менеджер пакетов, но, вероятно, это больше говорит о моей самоуверенности, чем об авторе пакета.
Удивило меня то, что эти пакеты были добавлены только в 2014 году, почти пять лет спустя после выпуска npm. Учитывая отсутствие препятствий к созданию новых пакетов npm (при условии соблюдения правил использования: https://docs.npmjs.com/policies/open-source-terms#acceptable-use), я удивлён, что пакет с таким простым именем был опубликован спустя столь долгое время.
crates.io был основан в 2014 году и тоже получил свою версию is-odd примерно через четыре года. Я думаю, это неизбежно для любого централизованного реестра пакетов.
Заслуживают ли эти пакеты ненависти?
Не думаю. Никто не заставляет вас их использовать. И они не занимаются «киберсквоттингом» имён, ведь делают именно то, что заявлено в названии (проверяют число на чётность или нечётность). Похоже, на них обрушилась ненависть, непропорциональная наносимому ими урону, который на самом деле намного меньше, чем у других более «полезных» пакетов наподобие left-pad, eslint-scope и node-ipc.
