Комментарии 53
npx yarn-dedup (по памяти) тоже прилично дубликатов вычистить может и уменьшить время сборки и размер бандла немного. А на проекте на TS ещё и от некоторых ошибок типов избавить
Не совсем понимаю, почему при установке пакета устанавливаются зависимости, которые нужны для его разработки? Разве установка пакета не должна подтягивать только его собранную версию + всякие README.md и так далее. Есть npmignore которые фильтрует файлы для npm, почему тогда при установке подтягиваются зависимости которые нужны только для разработки этого пакета ( если по факту, я не буду его собирать, а буду использовать собранный бандл этого пакета )
Я ведь говорю про пакеты, которые нужны для разработки. Зачем скачивать условный babel, если в пакете уже есть собранная версия js и по факту, мы не пересобираем пакет, а используем его бандл. Я вроде где-то слышал, что с пакетом должны скачиваться только зависимости из dependencies, но в реальности все как-то наоборот
В статье пишут, что при скачивании gastby качаются еще и остальные пакеты. Если посмотреть на package.json то там все зависимости в devDependencies, почему и зачем тогда они скачиваются? Щас лично проверил, что бы точно убедиться и установка yarn add gatsby качает еще и бабели, пакеты для тестов и так далее
Щас лично проверил, что бы точно убедиться и установка yarn add gatsby качает еще и бабели
Потому что он их использует не для разработки, а в деле. Т.е. это НЕ devDependencies.
если не указать явно список файлов (package.json/files), формирующих пакет, то по-умолчанию в пакет будут включены все файлы в каталоге. Например исходники не нужны при наличии уже собранного js файла.
Я лично разделаю package.json проекта и package.json пакета, формирующегося из проекта. В него попадает лишь необходимый минимум: собранный код, типы для TS, Readme.md. Также это даёт более явный контроль над зависимостями пакета.
Например исходники не нужны при наличии уже собранного js файла.
Для продакшена они не нужны, а вот когда при разработке пытаешься понять как работает та или иная зависимость...
Бесит неимоверно. Кому-то не хватает мозгов прописать files в package.json...А вам хватает мозгов зайти на гитхаб, создать issue или отправить pull request? Всё решаемо.
К тому же, обычно лишние файлы не видно, нужно специально лезть в модули, что делается крайне редко. Замечать это начинаешь когда inodes заканчиваются и тормозит IDE. Вот тогда и подбешивает, смотришь на размеры папок и сносишь модули в старых проектах.
Ну а какая альтернатива-то? Чтоб каждая зависимость содержала свои костыли вместо lodash? Ну на бэкенде еще относительно пофиг, а на фронте раздутые бандлы как-то не алё.
Тут, конечно, корни растут из относительно бедной стандартной библиотеки языка, и она потихоньку растёт, но продукт-то надо релизить прямо сейчас...
А я так и не понял, в чем проблема. Ну да, Gatsby требует кучу своих зависимостей. И хорошо, пусть требует. В мой package.json они не протекают, а в package-lock можно не смотреть, он вообще для чтения человеком не очень предназначен.
Так всё просто — есть проблема с одинаковым окружением. Кстати, решение этой проблемы сделало docker таким популярным, например. Тут типа того — разные версии пакетов, иногда и минорно, могут иметь разное поведение. И единственный адекватный кейс — всегда устанавливать именно то окружением что задумывалось разработчиком, иначе это будет порождать пляски с бубном на продакшене и прочее такое. Это плохо, уж лучше пакетов побольше, но всё же стабильная работа.
Ну и вторая причина количества пакетов вообще — любовь к мелкой модульности без таскания целых библиотек. Более того — некоторые популярные библиотеки представляют цельную версию и к ней по модулю на каждую входящую функцию — чтобы разработчик мог взять только одну или несколько, а не тащить с собой 100500 функций ради использования лишь одной. Разве это плохо? Вроде как очень даже хорошо. Ну а то что на npm сайте так много модулей — ну и что, больше выбора наоборот же.
В общем какая-то злая статья без понимания механизмов почему так. Не, конечно некоторые разработчики некоторых пакетов могут лишнее таскать, качество пакетов может быть сомнительным, как и эффективность — но так то это и в любом другом бывает, будь то Ruby или .NET экосистема. А с общим механизмом пакетов всё вполне себе.
И единственный адекватный кейс — всегда устанавливать именно то окружением что задумывалось разработчиком
Чуть ли не основной посыл поста, по-моему, что разработчики давно уже не контролируют окружение, просто фиксируют вариант "у меня работает", а что там конкретно работает без понятия, кроме явных зависимостей своего приложения.
Мне еще нравится, что при помощи webpack я не могу собрать оптимизированный bundle для node.js приложения. Это приводит к тому что вместо 200 килобайт, приложение под node.js весит 200 мегабайт. Это прям прекрасно.
Я пробовал, у меня с ходу не получилось. Там какие-то проблемы с тем что откуда читается, плюс nodejs отличается от web окружения. Хотите попробовать? Не ничего проще берете https://www.zigbee2mqtt.io/ и пытаетесь сделать из него рабочий бандл.
nodejs отличается от web окружения
Большая часть моего кода собирается под nodejs. Отличия есть, но они мизерные. Сделайте минимальное демо проблемы и киньте в ЛС/сюда, подскажу. Вебпак весьма ожидаемо работает. Не идеален, но в основном(не встречал другого) предсказуем.
Легко. Вот файл. После сборки в банл не запускается вот эта строка
https://github.com/Koenkk/zigbee2mqtt/blob/master/index.js#L5
Да поясню почему именно этот. Хочется запихнуть на embedded платформу, а там 128 мегабайт NAND. Если еще nodejs я туда со скрипом но утрамбую, но вот уже 200 мегабайт под модули и прочее барахло места не сказать что есть.
На вопрос "Эй чувак а чего ты туда вообще js потащил?" Спросите у всех кто IoT занимается. Там какая-то нездоровая тенденция лабать на JS.
А ну да поиск схожей проблемы дает знаете какой ответ? Дак вы соберите приложение в один js файл, а бандлы запакуйте в zip и распакуйте на сервере. Что-то такого я не ожидал.
Проблема осложняется тем, что в npm-модуль обычно попадает куча лишних файлов.
Например, возьмем vue. В папке dist у них лежит четырнадцать (!) вариантов собранного фреймворка общим весом 2.5мб с различными комбинациями вариантов: минифицированный\не минифицированный, c модулями CommonJS или ES Modules, для продакшена и нет. Рядом же есть папка source, в которой еще двести (!) файлов общим весом 500+ кб, чтобы можно было собрать все из исходников. Какой смысл поставлять одновременно и собранный вариант, и исходники для самостоятельной сборки? В некоторых подпапках также валяются системные файлы .DS_store, которые явно попали туда по недосмотру.
В bootstrap все то же самое, но еще есть две смешные папки: dist/js и js/dist. В первой собран весь код JS (опять же, 4 варианта с минификацией и прочим), а во второй он разделен на модули.
Но многие авторы вообще не парятся. Например, пакет promise-polyfill включает в себя: CHANGELOG.md, .editorconfig, .npmignore, .eslintrc.js, .travis.yml, а также тесты (тесты, Карл!) вместе с конфигом karma.conf.js. Зачем все это должно поставляться конечному потребителю?
И к сожалению, даже если исключить безалаберность разработчиков модулей и почистить весь хлам, более фундаментальная проблема разобщенности экосистемы останется. Очевидно, что авторы хотят сделать свои модули легко интегрируемыми в большинство проектов, но число комбинаций технологических стеков растет в астрономической прогрессии. В результате страдают все — одни от того, что конкретно их комбинация не поддерживается; другие — что помимо поддержки для их комбинации им приходится скачивать файлы для пары дюжин других.
Если это действительно является проблемой (например, не хочется тащить лишние файлы в прод), то можно воспользоваться modclean.
Тем не менее, они валяются на диске и тратят время при билде на CI. И нет абсолютно никакой уважительной причины, почему это так.
А какие у вас уважительные причины чего-то требовать от людей, которые бесплатно выложили в общий доступ полезные инструменты?
Я жалуюсь не на конкретных людей, а на экосистему в целом. Теория разбитых окон в действии — когда вокруг все вокруг на тройку, какой резон стараться сделать хорошо?
В основном я пишу на C#, поэтому есть с чем сравнить. Сама экосистема не так фрагментирована, есть богатая стандартная библиотека (поэтому нет нужды в вещах типа left-pad), nuget'ы практически всегда достаточно просто установить и все заработает, без мусора и доработки напильником. И все это настолько же открытое и бесплатное.
Место они кушают не однократно, а по количеству проектов, плюс также валяются в локальном кеше npm. И время они кушают не однократно, а при каждом билде на CI, т.к. он делается в чистой папке.
А теперь — принимайте поздравления. Только что в вашем проекте оказалось 19000 дополнительных зависимостей. Это нормально? Насколько сложным может стать дерево JavaScript-зависимостей? Как дерево зависимостей превращается в ад? Давайте с этим разберёмся.
Собственно, я не увидел постановки проблемы.
В чём конкретно заключаются претензии к разросшемуся дереву зависимостей? Чем это грозит? В чём заключаются экономические потери для проекта, прямые или косвенные?
Или речь уклончиво ведётся к размеру финального бандла, в который гипотетически может попасть то, что не должно? В этом случае грамотный импорт и tree shaking изрядно спасает ситуацию.
— писать всё самому
— доверять разработчикам пакета и их решению в выборе используемых зависимостей
Частично проблему с уязвимостями помогает понять audit, но соглашусь — не панацея.
Сокращение же количества зависимостей с 20 000 до 10 000 даёт, мягко говоря, опосредованное чувство защищённости. Оптимизация есть хорошо, но конкретно эта — не о безопасности, лишние телодвижения и полумеры.
Меня оскорбляет то, что на первом изображении Vue ниже чем Angular и React
Мне эта проблема долго не давала покоя, даже утилитку написал для того чтобы можно было быстро дерево зависимостей глянуть.
- В PHP каждый пакет в vendors может встречаться только однажды. Хочешь странного — извращайся на свой страх и риск (вариантов извращений немало — есть из чего выбрать). Это иногда заставляет страдать, потому что использовать конкретную версию конкретной библиотеки не получается, даже если очень срочно надо — не решается уравнение по разрешению зависимостей и всё тут. Но, с другой стороны — это всегда осознанные проблемы, которые нельзя «замести под ковёр» ни на каком уровне зависимостей. И на общем числе зависимостей это сказывается зело позитивно: несколько раз подумаешь, с кем завязывать отношения, а без кого можно и обойтись.
- В npm один и тот же пакет может существовать в нескольких версиях. Не просто один пакет в нескольких местах, а именно несколько версий одного пакета. Это делает
жизньдобавление пакетов проще, но… гораздо непредсказуемее. И технический долг неровным слоем размазывается на всю экосистему. В какой-то момент это просто обязано вынудить сообщество к каким-то эволюционным или революционным изменениям вотношенияхконфигурации зависимостей.
Что касается окружений, то в PHP есть только два варианта зависимостей: prod и dev. Это уменьшает число комбинаций.
Про содержимое продуктового пакета: к этому в PHP начинают относиться более строго всё большее количество крупных разработчиков. Продуктовые пакеты symfony, например, похудели очень ощутимо. Многие рецепты вполне универсальные и могут быть заимствованы напрямую в npm best practices.
Не знаю, насколько надумана проблема нескольких сборок под разные архитектуры, языки, размер (минифицированные или нет) и т.п. Всегда считал, что правильно не хранить вычисляемые вещи в репо, а возложить эту задачу на registry — собирать отдельные артефакты под каждую комбинацию. И сформулировать соглашение об именовании этих артефактов, с учётом версионирования. Наверняка, на это тоже есть какие-то причины… но выглядит костыльно.
В общем, имхо, если следующие версии npm явно запретят некоторые вольности, то с этим адом вполне можно будет совладать. И разработка от этого только выиграет.
Дорога в ад JavaScript-зависимостей