Что лучше, 15мб зависимостей или свой велосипед?
1,00
р.
При разработке публичного npm пакета часто возникает вопрос, использовать ли существующее решение, которое тянет с собой чуть-ли не половину всех популярных пакетов с npm, или написать свой велосипед.
Чтобы сузить область, уточню детали. Свой велосипед - это примерно 1000-1500 строк кода без зависимостей, естественно есть вероятность наделать много багов (но это как повезет). Время на разработку и отладку - день-два. Альтернатива - пакет который отлично решает эту задачу но тащит с собой ~150 вложенных зависимостей на ~15мб.
Как считаете, что предпочтительнее? И по каким критериям прежде всего решаете, какой сделать выбор в данной ситуации?
Ответ
В мире npm как то принято тянуть побольше зависимостей. И тут выход такой:
если это Ваш личный проект, тогда можно делать как нравится. В личных проектах велосипеды - самая правильная вещь (если цель проекта освоить новые технологии). если это проект "на попробовать", "взлетит/не взлетит" (ака стартап) - тогда побольше зависимостей, поменьше своего кода. Нам же идею проверять, инвесторов потенциальных радовать, а не код вылизывать. Потом, возможно, можно будет и переписать. если это проект рабочий (то есть, делается на работе), тогда лучше спросить у менеджера/тимлида/и тому подобное. Если сам тимлид/менеджер, тогда пункты выше. Но тут может оказаться, что юротдел может сказать, что некоторые пакеты имеют "неправильные лицензии" или "сомнительное происхождение" и их придется делать самому.
Но тут есть ещё одна штука. Нужно смотреть, а что за зависимости. Мало чего там. Может они конфиденциальную информацию собирают и в закрома засылают. И прецеденты уже были.
Мне также нравится следующая система. Собираем проект с готовых пакетов, смотрим, что бы лицензии у них были "хорошие, с возможностью модификации". А потом, когда проект "похоже работает", начинаем вычищать, переписывая критические участки. К примеру, можно использовать одну мелкую функцию с огромного пакета. Вполне возможно, что есть смысл ее извлечь в отдельный свой пакет. Хотя сейчас набегут хипстеры-оптимизаторы и скажут: "а вдруг завтра понадобиться ещё одна функция? и что извлекать снова? диски сейчас большие, памяти много, процессор пользователь докупит". Но таких нужно игнорировать и пользоваться здравым смыслом.
Чтобы сузить область, уточню детали. Свой велосипед - это примерно 1000-1500 строк кода без зависимостей, естественно есть вероятность наделать много багов (но это как повезет). Время на разработку и отладку - день-два. Альтернатива - пакет который отлично решает эту задачу но тащит с собой ~150 вложенных зависимостей на ~15мб.
Как считаете, что предпочтительнее? И по каким критериям прежде всего решаете, какой сделать выбор в данной ситуации?
Ответ
В мире npm как то принято тянуть побольше зависимостей. И тут выход такой:
если это Ваш личный проект, тогда можно делать как нравится. В личных проектах велосипеды - самая правильная вещь (если цель проекта освоить новые технологии). если это проект "на попробовать", "взлетит/не взлетит" (ака стартап) - тогда побольше зависимостей, поменьше своего кода. Нам же идею проверять, инвесторов потенциальных радовать, а не код вылизывать. Потом, возможно, можно будет и переписать. если это проект рабочий (то есть, делается на работе), тогда лучше спросить у менеджера/тимлида/и тому подобное. Если сам тимлид/менеджер, тогда пункты выше. Но тут может оказаться, что юротдел может сказать, что некоторые пакеты имеют "неправильные лицензии" или "сомнительное происхождение" и их придется делать самому.
Но тут есть ещё одна штука. Нужно смотреть, а что за зависимости. Мало чего там. Может они конфиденциальную информацию собирают и в закрома засылают. И прецеденты уже были.
Мне также нравится следующая система. Собираем проект с готовых пакетов, смотрим, что бы лицензии у них были "хорошие, с возможностью модификации". А потом, когда проект "похоже работает", начинаем вычищать, переписывая критические участки. К примеру, можно использовать одну мелкую функцию с огромного пакета. Вполне возможно, что есть смысл ее извлечь в отдельный свой пакет. Хотя сейчас набегут хипстеры-оптимизаторы и скажут: "а вдруг завтра понадобиться ещё одна функция? и что извлекать снова? диски сейчас большие, памяти много, процессор пользователь докупит". Но таких нужно игнорировать и пользоваться здравым смыслом.
