Как стать автором
Обновить

Комментарии 53

Самое забавное, что разработчики ничего не могут поделать ни с этим адом js-зависимостей в своём проекте, ни с этим постоянно меняющимся файлом package-lock.json. И скорее всего даже не осознают, что делает большая часть этих скачанных пакетов, не говоря уже о каком либо сознательном выборе определённых версий этих пакетов.

В целом могут, особенно если не использовать фреймворки. Но вот сроки…

Аж заснуть не могу, не знаю, что и поделать с этими зависимостями

Поэтому они так и называются «зависимости». Потому что от них у разработчиков зависимость.

npx yarn-dedup (по памяти) тоже прилично дубликатов вычистить может и уменьшить время сборки и размер бандла немного. А на проекте на TS ещё и от некоторых ошибок типов избавить

Не совсем понимаю, почему при установке пакета устанавливаются зависимости, которые нужны для его разработки? Разве установка пакета не должна подтягивать только его собранную версию + всякие README.md и так далее. Есть npmignore которые фильтрует файлы для npm, почему тогда при установке подтягиваются зависимости которые нужны только для разработки этого пакета ( если по факту, я не буду его собирать, а буду использовать собранный бандл этого пакета )

Потому что собранный бандл пакета обычно содержит только код самого пакета, без зависимостей

Я ведь говорю про пакеты, которые нужны для разработки. Зачем скачивать условный babel, если в пакете уже есть собранная версия js и по факту, мы не пересобираем пакет, а используем его бандл. Я вроде где-то слышал, что с пакетом должны скачиваться только зависимости из dependencies, но в реальности все как-то наоборот

Да нет, devDependencies зависимостей не скачиваются.

В статье пишут, что при скачивании gastby качаются еще и остальные пакеты. Если посмотреть на package.json то там все зависимости в devDependencies, почему и зачем тогда они скачиваются? Щас лично проверил, что бы точно убедиться и установка yarn add gatsby качает еще и бабели, пакеты для тестов и так далее

Вы смотрите не в тот package.json. Это общие пакеты для монорепозитория. Вот package.json конкретно пакета gatsby
Щас лично проверил, что бы точно убедиться и установка yarn add gatsby качает еще и бабели

Потому что он их использует не для разработки, а в деле. Т.е. это НЕ devDependencies.

Люто плюсую. Бесит неимоверно. Кому-то не хватает мозгов прописать files в package.json и мы получаем +100500 кб нафиг ненужного барахла
раскройте пожалуйста тему

если не указать явно список файлов (package.json/files), формирующих пакет, то по-умолчанию в пакет будут включены все файлы в каталоге. Например исходники не нужны при наличии уже собранного js файла.


Я лично разделаю package.json проекта и package.json пакета, формирующегося из проекта. В него попадает лишь необходимый минимум: собранный код, типы для TS, Readme.md. Также это даёт более явный контроль над зависимостями пакета.

Например исходники не нужны при наличии уже собранного js файла.

Для продакшена они не нужны, а вот когда при разработке пытаешься понять как работает та или иная зависимость...

А для этого есть GitHub и ссылка в package.json/repository. Это не настолько частая необходимость, чтобы оправдать раздувание node_modules.

Для меня очень частая. Тут больше особенность самих npm/yarn — просто тупо делят зависимости на дев-билд (причём нет единого мнения в коммьюнити, что куда относится, куда входят зависимости для билда, например) без возможности указывать загружать исходники при наличии "бинарников" или нет.

Бесит неимоверно. Кому-то не хватает мозгов прописать files в package.json...
А вам хватает мозгов зайти на гитхаб, создать issue или отправить pull request? Всё решаемо.
Чего это вы так взбеленились? Это ваши модули? С чего вы взяли что я не создаю issue? Я на такое ругался еще со времен jquery плагинов и browserify, который этим то же страдал даже в большей степени.
К тому же, обычно лишние файлы не видно, нужно специально лезть в модули, что делается крайне редко. Замечать это начинаешь когда inodes заканчиваются и тормозит IDE. Вот тогда и подбешивает, смотришь на размеры папок и сносишь модули в старых проектах.
Чего это вы так взбеленились? Это ваши модули? С чего вы взяли что я не создаю issue?
Я просто задал вопрос в Вашей манере. Часто вижу, что люди могут только ругаться, не прилагая никаких усилий для исправления недочётов. Но Вы не такой, это радует.

Ну а какая альтернатива-то? Чтоб каждая зависимость содержала свои костыли вместо 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. Отличия есть, но они мизерные. Сделайте минимальное демо проблемы и киньте в ЛС/сюда, подскажу. Вебпак весьма ожидаемо работает. Не идеален, но в основном(не встречал другого) предсказуем.

Да поясню почему именно этот. Хочется запихнуть на 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'ы практически всегда достаточно просто установить и все заработает, без мусора и доработки напильником. И все это настолько же открытое и бесплатное.

а как вам мешают лежащие в папке dist вариации сборки, кроме как кушают место и время однократно, при инсталле?

Место они кушают не однократно, а по количеству проектов, плюс также валяются в локальном кеше npm. И время они кушают не однократно, а при каждом билде на CI, т.к. он делается в чистой папке.

Насчёт места — посмотрите в сторону pnpm
А теперь — принимайте поздравления. Только что в вашем проекте оказалось 19000 дополнительных зависимостей. Это нормально? Насколько сложным может стать дерево JavaScript-зависимостей? Как дерево зависимостей превращается в ад? Давайте с этим разберёмся.


Собственно, я не увидел постановки проблемы.

В чём конкретно заключаются претензии к разросшемуся дереву зависимостей? Чем это грозит? В чём заключаются экономические потери для проекта, прямые или косвенные?

Или речь уклончиво ведётся к размеру финального бандла, в который гипотетически может попасть то, что не должно? В этом случае грамотный импорт и tree shaking изрядно спасает ситуацию.
как вы понимаете, варианта два:
— писать всё самому
— доверять разработчикам пакета и их решению в выборе используемых зависимостей

Частично проблему с уязвимостями помогает понять audit, но соглашусь — не панацея.

Сокращение же количества зависимостей с 20 000 до 10 000 даёт, мягко говоря, опосредованное чувство защищённости. Оптимизация есть хорошо, но конкретно эта — не о безопасности, лишние телодвижения и полумеры.

Меня оскорбляет то, что на первом изображении Vue ниже чем Angular и React

Спасибо за статью
RxJS, конечно, удивил. Он же проде как рекламируется как легкий?

Мне эта проблема долго не давала покоя, даже утилитку написал для того чтобы можно было быстро дерево зависимостей глянуть.

У вас опечатка в README:

Why should I cate about my package size?
Сам разрабатываю на PHP, но без NPM, разумеется обойтись не могу. Если сравнивать с PHP Composer, то налицо разница в концепциях:

  • В PHP каждый пакет в vendors может встречаться только однажды. Хочешь странного — извращайся на свой страх и риск (вариантов извращений немало — есть из чего выбрать). Это иногда заставляет страдать, потому что использовать конкретную версию конкретной библиотеки не получается, даже если очень срочно надо — не решается уравнение по разрешению зависимостей и всё тут. Но, с другой стороны — это всегда осознанные проблемы, которые нельзя «замести под ковёр» ни на каком уровне зависимостей. И на общем числе зависимостей это сказывается зело позитивно: несколько раз подумаешь, с кем завязывать отношения, а без кого можно и обойтись.
  • В npm один и тот же пакет может существовать в нескольких версиях. Не просто один пакет в нескольких местах, а именно несколько версий одного пакета. Это делает жизнь добавление пакетов проще, но… гораздо непредсказуемее. И технический долг неровным слоем размазывается на всю экосистему. В какой-то момент это просто обязано вынудить сообщество к каким-то эволюционным или революционным изменениям в отношениях конфигурации зависимостей.


Что касается окружений, то в PHP есть только два варианта зависимостей: prod и dev. Это уменьшает число комбинаций.

Про содержимое продуктового пакета: к этому в PHP начинают относиться более строго всё большее количество крупных разработчиков. Продуктовые пакеты symfony, например, похудели очень ощутимо. Многие рецепты вполне универсальные и могут быть заимствованы напрямую в npm best practices.

Не знаю, насколько надумана проблема нескольких сборок под разные архитектуры, языки, размер (минифицированные или нет) и т.п. Всегда считал, что правильно не хранить вычисляемые вещи в репо, а возложить эту задачу на registry — собирать отдельные артефакты под каждую комбинацию. И сформулировать соглашение об именовании этих артефактов, с учётом версионирования. Наверняка, на это тоже есть какие-то причины… но выглядит костыльно.

В общем, имхо, если следующие версии npm явно запретят некоторые вольности, то с этим адом вполне можно будет совладать. И разработка от этого только выиграет.
Я ожидал от этой статьи скорее «почему это плохо». Например, что ошибка в одном из очень используемых пакетов приведет к падению огромного количества проектов при обновлении. Или, например, долгую компиляцию на серверной стороне (или долгое выкачивание зависимостей, что сильно осложняет CI/CD). Или необходимость выкачивать в браузере большое количество не полностью используемых скриптов… И все это со ссылками конкретно на ваш случай…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.