Comments 79
Принцип DRY, доведённый до абсурда...
Т.е. импортируют пакет ради проверки is-a? Напоминает старую шутку про jQuery a+b.
Мне кажется, это не простота, а неуверенность в своём кругозоре. Слишком часто бывают ситуации, когда забыл предусмотреть какие-то варианты. Например, в домашнем проекте мобильный браузер можно определить по наличию ontouchstart у document.body, а на работе нужно учесть, что бывают компьютеры и ноутбуки с сенсорным экраном и ещё какие-то варианты, и поэтому "какой-нибудь дядя, который занимался этим вопросом настолько, что сделал отдельный пакет, всяко лучше меня подумал над вопросом", а ещё "есть очень большой шанс, что тот дядя был из числа людей, которые обычно пишут отзывы, что программист за 30 тысяч рублей ничего не умеет, а то получал бы в 10 раз больше, и следовательно, этот дядя точно лучше знает, как решать любую задачу".
На крайний случай можно скопировать код себе было, особенно если он из 2 строчек. Либо переписать на свой код, основываясь на чужом.
Потому что любая зависимость — потенциально +1 уязвимость.
99% того что папишут руками есть на stackoverflow (не говоря о том что библиотека может быть копипастой оттуда, при этом без учёта прав), авторское право оно такое, странное. :)
Тогда не будешь получать обновлений опыта «дяди», а в JS это важно в связи с тем, что постоянно появляются новые API и особенности браузеров
И много обновлений нужно для функции проверки на промис? Если стандартное API обновится и вдруг появятся новые определения промиса, на крайний случай можно будет потратить несколько минут на обновление функции. Это стоит того, чтобы не тащить лишнюю зависимостью в проект.
Мой аргумент в общем про подход, а не про конкретный пример. Но даже в нём могут вскрыться нюансы. Например, судя по исходному JS-коду этой функции, она не проверяет наличие в объекте метода catch. Может оказаться, что из-за её отсутствия происходит баг, и автор репозитория починил это баг. Вручную проверять актуальность подобных мелочей — та ещё рутина.
Что является промисом — объяснено в доках, например, на MDN. Написать свою функцию или на крайний случай проверить чужую — дело минут. Обновление такой функции не понадобится. Проверять актуальность не понадобится.
При этом самое интересное, что очень часто в таких случаях автор сам не читал, что является промисом, и сделал неправильную реализацию. Проверить так и так придётся его.
И потратить эти минуты — это намного лучше, чем чтобы твоим пакетом вообще потом не смогли пользоваться из-за лишней зависимости.
Если стандартное API обновится и вдруг появятся новые определения промиса, на крайний случай можно будет потратить несколько минут на обновление функции.
Для начала вам нужно будет понять когда и что и где делать и делать ли или это обновление ваш код минует. Это не несколько минут. Одно только понимания факта что нужно обновить, одно только заметить что нужно обновить — это уже куча времени.
А теперь посчитайте сколько таких вещей в вашем коде.
0xf0a00
Ну да, ведь код какого то нонейма из npm 100% надежен, протестирован и в нем точно все учтено. И он точно лучше чем тот код который написали вы лично сами зная свою специфику проекта…
Как минимум он уже существует. Что экономит вам время. Немного тут, немного там. В итоге огромная экономия.
Представьте себе, что это код вашего коллеги, что работает в соседнем кабинете. Примерно то же самое по надежности.
И да, если вы его используете постоянно, вы лично его уже протестили на реальных проектах и поняли, что он для вас годится. При том что денег за его поддержку не тратится (тратится не вашей организацией).
Вот судя по таким комментам я понимаю что ну реально непрошибаемые идиоты какие то… вам наглядный пример что миллионы мух могут ошибаться, но нет… вот просто не доходит.
«Ах что это, мне ж придется писать код, проверять самому..» Да *лять! Тебе деньги платят за то что ты код пишешь! Понимаю что не хочется, хочется полениться и в ютубик позалипать, но ты уж будь добр попиши хоть чуть чуть, чем таскать такую элементарщину из npm.
Да и обновление отдельной функции или двух, но в 20 проектах, может быть сложным, если эти функции не вынесены в отдельный файл. Придётся лезть в файл, где они объявлены, и вручную вносить правки. Да, не у всех код настолько хорошо структурирован, особенно был годы тому назад.
Зато, если это сторонний пакет, то он просто обновляется весь.
нужно будет понять
Понять так и так будет нужно. Если каким-то чудом изменится определение промиса, ты обязан будешь это знать.
Представьте себе, что это код вашего коллеги
Представьте, что это код какого-нибудь хакера или человека, репозиторий которого вот-вот взломают.
Пакеты — хорошая вещь, они экономят время да. Но имеются ввиду большие пакеты, а не из 10 строк. Например, нет смысла писать свой парсер XML — это действительно немалый проект. Такие вещи нужно подключать, да. Риск взлома есть, но достоинства перевешивают недостатки. А вот подключать фигню из 2 строк — недостатки явно перевешивают достоинства.
Также допустимо подключать пакеты, в которых есть сразу много мелких функций. Каждая из них не очень большая, но суммарно ты заимствуешь сразу много кода, и опять же, преимущества могут перевесить риски.
Вот Вы привели пример коллеги. Представьте, если бы мы наняли этого коллегу, чтобы написать в проекте 2 строчки кода. Ну не глупо ли это? Нужен определённый объём кода, чтобы достоинства превысили недостатки.
И снова — коллега и какой-то незнакомый человек, которого ты никогда не видел, с которым никогда не работал и вообще ничего про него не знаешь — не одно и тоже.
stackoverflow.com/a/8511332
А как насчёт такого isPromise — «это promise если там есть метод „then“, но вообще вам не надо знать, что это promise». Даже учитывая, что прошло 5 лет — вечность по меркам JS — но всё равно, WAT?
stackoverflow.com/a/27746324
(За 5 лет, кстати, существенно ничего не изменилось. Упомянутый пакет делает то же самое)
return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof
obj.then === 'function';
}Бег по граблям как национальный вид спорта.
Несомненно, в языке есть изъяны. Это немного другой вопрос, но у я бы хотел высказать мнение, что в JS есть много странностей, потому что в отличие от многих других языков у него серьёзные требования к обратной совместимости. Производители браузеров не могут просто выкатить JS2, в котором выкинуто всё странное легаси, потому что практически все сайты перестанут работать.
В любом случае, изъяны надо как-то обходить. Мини-пакеты это не идеальный способ обходить их.
Я не JS программист, но ведь в общем это действительно справедливо:
1) Проверка чего бы то ни было — только на первый взгляд тривиальна. Если вам кажется что это не так, то вы или неглубоко копнули, или ваш проект однодневка и не предполагается, что он будет работать лет 10 хотя бы. Хотя конечно, можно и самому нагородить однострочных функций в какой-нибудь базовый модуль, но за 10 лет таких функций накопится столько, что нужно будет нанять еще одно программиста просто поддерживать это месиво.
2) Програмиист за 30 тысяч рублей СКОРЕЕ ВСЕГО ничего не умеет. Это конечно может быть очень скромный самородок, которого нагло эксплуатирует компания, или же человек всецело преданный какой-то идее внутри сферы, в которой работает. Всё это редкость и чаще всего мы имеем именно ситуацию, когда программист за 30 тысяч действительно не очень (еще, потому что джун, или совсем, причин масса). Иначе он бы давно уже нашел себе работу получше)
А нужно было скопировать is-even, изменить в нем один знак и объявить самостоятельным модулем?
Сорри, я не потроллить, я не из мира JS и действительно не понимаю.
И переопределить для него операции "+", "-" и X (векторное умножение [a,b]).
(Да я знаю про тришейкинг, но всё равно нет).
В случае, если JS имел бы Stdlib, его бы включали в браузер вместе с движком JS, и количество загружаемых с сайтов NPM модулей упало бы на порядок.
Правда была бы другая проблема — производители браузеров воевали бы за развитие stdlib, как в ситуации с CSS (я про все эти префиксы типа -moz-support-for-some-modern-non-standartized-bullshit).
Благо сейчас CSS3 поддерживает уже такую кучу функций, что новые особо никому и не нужны.
Не надо использовать Guava если вы не используете GWT.
Тестировал в jmh года полтора назад.
lodash/underscore/ramda
Ну, одно время было что-то подобное ввиде JQuery. Но сейчас в экосистеме JS любая stdlib просуществует не дольше месяца, пока очередной школьник ни накропает свою с блекджеком и пр...
Нечто подобное произошло в марте 2016 года, когда автор библиотеки left-pad (из 17 строк кода) решил ни с того ни с сего отозвать свою библиотеку, чуть не сломав подобным образом тысячи проектов.
Ничего себе "ни с того ни с сего", всего-то за автора и владельца модуля, и против его решения, решили "как оно должно быть" в пользу нонейм фирмы.
И последующий результат "Твой код это не твой код если ну очень хочется" тоже прекрасен.
"Твой код это не твой код если ну очень хочется"
Код был открыт (на момент удаления под WTFPL), так что именно это не такая большая проблема.
Это плохо смотрится с точки зрения доверия к npm, но первая часть той истории с отжимом kik выглядит настолько сильно хуже, что только полный пофигизм js-разработчиков все ещё держит npm на плаву
Кстати про instanceof. В CScript под Windows нет JSON парсера. Я взял хак со StackOverflow который:
var htmlfile = WSH.CreateObject('htmlfile'), JSON;
htmlfile.write('<meta http-equiv="x-ua-compatible" content="IE=9" />');
htmlfile.close(JSON = htmlfile.parentWindow.JSON);Так оказалось что:
var a = JSON.parse ("[1,2,3]");
WScript.Echo (a instanceof Array ? "Array" : "Not Array") // Not Array
WScript.Echo (JSON.stringify ([])) // {}
Если на проекте разные команды программистов и одна уже хочет в прод брать фичи 13.x, а остальные не успевают проверить совместимость старого кода — нужно как-то решать.
Набросал простенький пример, демонстрирующий эту проблему: github.com/SagePtr/test-issue452
А в nodejs эту проблему зарепортили? А то сейчас кажется, что они и не в курсе
npm i учитывает файл package-lock.json. npm ci для другого.
В package-lock.json указаны конкретные номера версий всех зависимостей и подзависимостей без модификаторов типо ^, ~ и *. К тому же там указаны ожидаемые хэш-суммы пакетов. NPM устанавливает ровно те версии, которые указаны в этом файле.
https://docs.npmjs.com/cli/install
https://docs.npmjs.com/files/package-lock.json
Библиотека is-promise состоит из двух строк кода, а разработчики могут использовать её в своих проектах с помощью однострочного вызова.
declare function isPromise<T, S>(obj: Promise<T> | S): obj is Promise<T>; export default isPromise;
Извините, а где здесь вызов? Тут вообще нет ни одной строчки Javascript-кода.
Во-первых, проблема не в коде is-promise (благо этого кода в нём ровно одна строка и он не менялся), а в смене технологии модуля. Проще говоря, is-promise изменил packaging, и в зависимых пакетах из-за этого кое-где (не везде) сломались импорты/require.
Во-вторых, корневая причина ситуации — головотяпство авторов, выпустивших это изменение как minor version, в то время как по нормативам semver это должна быть major version (с breaking changes).
Собственно, сейчас они уже исправились, выпустив это всё как 3.0.0. Как сразу и надо было сделать.
Объем кода в is-promise тут вообще не при чём. Это мог быть и однострочник, и большой пакет, и вообще что угодно.
ЗЫ: В-третьих, учитывая, что модульных оберток в экосистеме JS с учётом ноды — сейчас 4 штуки (AMD, UMD, CommonJS, ES modules), эта ситуация совершенно обыденная, на самом деле. Разве что бомбануло чуть шире обычного из-за количества зависимостей.
корневая причина ситуации — головотяпство авторов, выпустивших это изменение как minor version, в то время как по нормативам semver это должна быть major version (с breaking changes)
Да, но нет. Всё-таки, если человек не хочет поломок из-за зависимостей, он должен фризить версии полностью — вплоть до минорных (а ещё точнее — фризить с проверкой хэша).
Полагаться на семантическое версионирование — полагаться на честность и отсутствие ошибок у посторонних людей. Делать это стоит только, если код покрыт тестами.
Проблема не в зависимостях. И не в однострочниках. Что, если следующий баг будет в более крупной библиотеке? Реальная проблема состоит из трех частей:
- Недостаточно точные версии зависимостей. Судя по файлам вида yarn.lock в большинстве репозиториев, на фронте наконец-то догадались сохранять точные версии используемых либ.
- Централизация. Если упадет npm, то навернутся вообще все CI, кроме тех, которые у себя держат реестр используемых пакетов. В общем-то, аналогичная ситуация и с докером.
- Нельзя менять уже существующие версии пакетов. Опубликовал в опен-сорс либу версии 1.0.0 — всё, хоть ты тресни, тебе больше нельзя её удалить или поменять там что-то, не увеличив перед этим номер версии. Не хочешь, чтобы люди ей пользовались — ну извини, надо было раньше думать.
Ну и реальная проблема есть, что в js маловата стандартная либа. Что-то вроде lodash давно пора включить во все сборки браузеров. На других-то языках пофиг, а тут каждые 10кб важны, и приходится раз за разом заново писать отдельные функции, вместо того чтобы тупо импортировать либу целиком.
Что-то вроде lodash давно пора включить во все сборки браузеров.
Современный стандарт языка делает lodash на 90% не нужным вообще, а оставшиеся 10% — то, что нужно далеко-далеко не всем. Так что вообще-то уже де-факто включили.
Ложь!
lodash умеет работать с объектами там где js только с массивами.
.map, .filter и так далее.
Современный стандарт языка делает lodash на 90% не нужным вообще
Откройте документацию лодаша и посмотрите что скорее наоборот, es6 может только 10% функций lodash реализовать в такое же количество строк. Я выделил жирным важную часть
Также лодаш "умнее / гибче" и может во многие функции принимать в качестве предиката строки, например _.filter(users, 'isActive') аналог users.filter(user => user.isActive)
Что согласитесь слегка удобнее. А еще удобнее передать туда объект
_.filter(users, {name: 'Alex', age: 12}) вместо users.filter(user => user.name === 'Alex' && user.age === 12)
lodash умеет работать с объектами там где js только с массивами.
.map, .filter и так далее.
В 2020 году вам уже стоит открыть для себя Object.keys(), Object.values(), и главное — Object.entries().
Также лодаш «умнее / гибче» и может во многие функции принимать в качестве предиката строки, например _.filter(users, 'isActive') аналог users.filter(user => user.isActive)
Это достаточно бессмысленный сахар, который только затрудняет чтение кода, экономя максимум десяток-другой букв. Более того, хоть и это можно тайпчекать TS (чтоб не сломать код, опечавшись в строке), то рефакторить средствами IDE это всё равно нельзя, если вы захотите isActive переименовать, то все ваши строки будете переименовывать отдельно через text replace, а если захватите реплейсом что-нибудь лишнее — ну, удачи.
В 2020 году вам уже стоит открыть для себя Object.keys(), Object.values(), и главное — Object.entries().
то есть скажем вот это
Object.values(users).filter(user => user.name === 'Alex' && user.age === 12)
удобнее чем
_.filter(users, {name: 'Alex', age: 12})
?
Или вот что насчет _.mapValues?
В случае Object.entries нам придется массив потом обратно в объект превращать, а я не уверен что для этого есть просто способ в js
Или например такие функции как intersection, take, uniq (только не надо мне скидывать ужас с [...Set()] это на конкурс ребусов по разгадке древнегреческого), countBy, groupBy, partition, sampleSize, shuffle, curry, memoize, throttle, cloneDeep, meanBy, minBy (тут конечно есть около адекватный Math.min(...arr.map(it => it.something)))
и много других функций.
Это достаточно бессмысленный сахар, который только затрудняет чтение кода, экономя максимум десяток-другой букв
Дело не в буквах, дело в том что код становится более легким для восприятия. Ну согласитесь что вот это user => user.name === 'Alex' && user.age === 12 сложнее чем {name: 'Alex', age: 12}
А что делать если интересует ключей больше?
user.name === 'Alex' && user.age === 12 && user.role === 'admin && user.signinDate === someDate
против
{name: Alex, age: 12, role: 'admin', signinDate: someDate}
то рефакторить средствами IDE это всё равно нельзя, если вы захотите isActive переименовать
Частично согласен, но разве IDE понимает что в стрелочных функциях свойства относятся к кому-то?
Я имею в виду, будет ли работать рефакторинг в IDE если у нас есть две разные сущности с одинаковым свойством
users = [{isActive: true}, ...]
accounts = [{isActive: true},...]
И где-то есть стрелочная функция которая работает с этим свойством
users.map(user => user.isActive ...)
accounts.map(account => account.isActive ...)
То если мы изменим isActive только в юзере, но не к аккаунте, разве IDE сможет изменить стрелочную фунцкию user => user.isActive ?
В случае Object.entries нам придется массив потом обратно в объект превращать, а я не уверен что для этого есть просто способ в js
Object.fromEntries()
Или например такие функции как intersection, take, uniq (только не надо мне скидывать ужас с [...Set()] это на конкурс ребусов по разгадке древнегреческого), countBy, groupBy, partition, sampleSize, shuffle, curry, memoize, throttle, cloneDeep, meanBy, minBy (тут конечно есть около адекватный Math.min(...arr.map(it => it.something)))
Часть этих вещей как раз входит в оставшиеся 10%, а другая часть тривиально пишется в 1-2 строчки самостоятельно.
Дело не в буквах, дело в том что код становится более легким для восприятия.
const compare = (a: object, b: object): boolean =>
Object.entries(b).every(entry => entry[1] === a[entry[0]]Надо ли мне ради такого кода влеплять lodash в зависимости, или его всё-таки можно самому написать, как вы считаете?
Частично согласен, но разве IDE понимает что в стрелочных функциях свойства относятся к кому-то?
В TS IDE будет рефакторить по типам TS — так что там, да, всё будет отрефакторено правильно. В JS — как повезет, но вообще современные IDE делают статанализ по JS крайне неплохо, и в прямолинейно написанных случаях скорее всего отрефакторят всё как надо.
Object.fromEntries()
Спасибо, не знал.
Но все равно, то что лодаш делает в один этап
_.mapValues(users, user => user.age)
без лодаша будет делатся в три этапа, из объекта в массив, мап, из массива в объект.
Object.fromEntries(Object.entries(users).map((userKey, user) => [userKey, user.age]))
согласитесь, это выглядит жутко.
Надо ли мне ради такого кода влеплять lodash в зависимости, или его всё-таки можно самому написать, как вы считаете?
Я считаю что на любом проекте будет несколько таких "однострочников" которые лодаш заменяет лучше. Ради одного раза разумеется не стоит.
Более того, представьте что вам нужно глубокое, а не поверхностное сравнение, что тогда?
В TS IDE будет рефакторить по типам TS — так что там, да, всё будет отрефакторено правильно
окей, в любом случае лодаш позволяет, но не заставляет использовать _.map(filter, 'string'). Кому-то это нравится, кому-то нет. Где-то это удобное, где-то нет.
Более того, представьте что вам нужно глубокое, а не поверхностное сравнение, что тогда?
Это очень сильно зависит от деталей ситуации: я бы далеко не всегда пользовался лодашевскими «фичами» по сравнению вглубь — они а) медленные; б) весьма замороченные, но даже не смотря на это — в) не могут претендовать на всеобъемлюще правильное сравнение (зависит от того, что именно вы сравниваете).
К слову, если вы ничего «такого» не держите в своих объектах, то глубокое сравнение (и глубокое клонирование) через JSON.stringify будет значительно быстрее лодаша. Если держите — зависит от того, что вы именно держите. На проксях и прочих очень нетривиальных вещах лодаш сфейлится.
Я считаю что на любом проекте будет несколько таких «однострочников» которые лодаш заменяет лучше. Ради одного раза разумеется не стоит.
В том-то и дело, что он их не «заменяет лучше», а буквально делает то же самое. Тащить себе сторонние пакеты уровня left-pad и is-promise — моветон, даже если это не один условный is-promise, а сразу 10. Всё равно оно остаётся тривиальным однострочником, 10 которых написать самому займет примерно столько же времени, сколько подключить лодаш и убедиться, что он три-шейкается.
согласитесь, это выглядит жутко
Ничего жуткого. Чуть длиннее — но это всё та же формальная конструкция-однострочник, которую можно всё так же вынести в функцию с красивым названием, если очень хочется.
Проблема привлечения таких вот библиотек как раз в том, что вы потом так просто не скажете, где у вас из них взяты простые и очевидные однострочники, как тот же mapValues, а где вы уже залезли в длинную витиеватую логику с множеством граничных случаев, как то же клонирование объектов.
_.mapValues(users, user => user.age)
Вы под «капот» заглядывали? Загляните — после этого перестанете так утверждать. Только в этом методе используется куча подвызовов
Пожалуйста, ради любви ко всему, что представляет собой программирование, самостоятельно напишите проклятые базовые функции
Уважаемый Девид Хейни по-моему слишком много на себя берёт. Он говорит так, будто бы единственная проблема, которую решает установка сторонних модулей — это нежелание написать простой код. А помимо этого модули также решают как минимум проблему поддержки и повторного использования кода. Ну вот нужна мне функция isPromise. Причём нужна мне она в паре десятков проектов. Мне что, в каждом из них создавать, простигосподи, папку utils? И из проекта в проект копипастить эту одну строчку кода? Конечно нет. Да я как только поймаю себя на мысли о том, что я собираюсь создать папку utils, тут же либо полезу искать готовый npm модуль, либо, если не найду его, создам его сам и опубликую в npm, что бы во следующем проекте установить его же. Это нормальный эволюционный путь.
А Девид Хейни, вроде взрослый человек, ведущий инженер StackOverflow, а как ребёнок рассуждает.
Если я так буду распыляться, то я проекты буду делать раза в два дольше, а если каждый так делать будет, то в NPM будут тысячи одинаковых библиотек от разных разработчиков.
У NPM и так есть эта проблема, только в гораздо меньшем масштабе. Зачем раздувать её ещё сильнее?
Всегда приходится чем-то жертвовать ради чего-то. В данном случае разработчики пожертвовали стабильностью ради того, что бы сэкономить 3-4 часа жизни, а то и все 8. И это только ради одной библиотеки is-promise. А вообще подобных мелких библиотек множество, и каждый день разработчики устанавливают разные мелкие библиотеки, экономя время до выхода на рынок. И то, что в одном из миллиона случаев это привело к краху, причём совершенно не критичному, не значит, что надо отказываться от этого подхода и срочно всем клепать по своей собственной библиотеке с блэкджеком.
Прикол в том, что на деле-то ничего страшного не произошло. Да, масштабно, по всему миру прокатилось, но никаких последствий от этого не было. А раздули будто бы банковскую систему положили на несколько недель.
Ещё один однострочный пакет npm сломал экосистему JavaScript