node_modules знаком любому разработчику, чья работа связана с JavaScript плеера, что, кстати, не так уж и важно, может быть, потому, что мы уже видели это и не осмелились говорить о том, что на самом деле скрывается под капотом. Так что найдите минутку, чтобы на самом деле подумать, действительно ли вы думали о том, в чем причина вызова, для некоторых определенных команд npm install это в конечном итоге занимает четверть времени. размер вашего диска, ваше время, ваше недовольство, время вашего сна в офисе, чтобы посмотреть Netflix и расслабиться ... и этот список можно продолжить, не так ли?

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

Перед этим давайте перефразируем историю с молотком.

Когда дело доходит до поиска решений современных проблем, люди часто думают, что вам не нужно думать об инструментах, которые вам нужны для работы. Если вам нужен молоток на 20 кг, чтобы забить гвоздь, вы просто берете его. Та же история с node_modules, он может весить несколько килобайт или несколько мегабайт, потому что наш воображаемый молот идет с набором тяжелых гвоздей, верно? Ну может быть, в теории. Посмотрите на молот Тора по этой причине. Вы когда-нибудь задумывались о том, насколько тяжелым он мог быть?

Я знаю... мы не можем поднять Мьёльнир, но как здорово было бы править Асгардом 🤩

Итак, чтобы прояснить не тему Hammer, а указанный выше пункт о регрессии к разговору о node_modules, давайте проследим. В настоящее время, поскольку я специалист по Angular, я приведу реальный пример, который мы все уже сделали бы, чтобы изучить некоторые зависимости @angular/cli,только потому что это довольно большая библиотека. Я не хочу, чтобы это выглядело плохо, но это просто хорошее представление среднего пакета. Я установил его в пустой каталог, используя [email protected] и забавный факт: Npm сообщил, что после установки добавлено 272 пакета от 207 участников и проверено 2899 пакетов за 53,596 с.

Что интересно, так это аргументы, которые были высказаны еще в 2017 году по сравнению с установкой @angular/cli в результате использования [email protected]. Npm сообщил добавлено 976 пакетов за 107,13 с после установки (это 141 мегабайт на диске)согласно одной из статей, на которые я ссылался в Hackernoon.

Кстати, это показывает нам улучшения, которые Google сделал с более поздними версиями Angular по сравнению с версией 2 года назад. Видимое уменьшение поддерживаемых файлов с 976 пакетов до 272 пакетов, а также видимое уменьшение размера диска, который он приобретает сейчас (38 МБ) по сравнению со 141 МБ в 2017 году.

@angular/cli — отличный пакет со своим списком зависимостей, которые, я считаю, нужны всем. В упомянутой статье Hackernoon они сосредоточились на пакете common-tags.

Точно так же Handlebars,если говорить о его документации, это своего рода библиотека утилит для манипулирования строками. Это базовый уровень реализации, необходимый любому разработчику, поэтому никакого вреда не будет. Но в 2020 году в текущей последней версии Angular (v9) тегов создания нигде нет. Поэтому их аргумент не может быть воссоздан с 2020 года с текущей версией @angular/cli. Но, по сути, то же самое происходит и под капотом в 2020 году.

Это может быть не заметно в более прогрессивно отодвинутом на задний план проекте, таком как @angular/cli, но когда дело доходит до более узких примеров из реального мира, таких как ng new blah blah, все еще есть доказательства обратного. Тем не менее, если внимательно проанализировать сценарий @angular/cli, можно обнаружить странное поведение, которое приводит к проблеме изменения размера.

По своей сути он использует всего 167 файлов из 272 установленных пакетов.

По сравнению с размещением файлов и другими свойствами, приведенные ниже пункты должны быть перепроверены для нескольких сценариев, что в большинстве случаев достаточно, чтобы быть правдой. Из пакетов, которые устанавливаются,

  • несколько пакетов для решения темы «querystring»
  • некоторые попытки для методов assert различной сложности от minimalistic-assert до assert-plus
  • десятки различных is-* пакетов
  • множествопакетов для «приукрашивания» ошибок и выводов консоли
  • сотни полифилов/прокладок или повторная реализация нативных методов
  • конечно, предыдущие утверждения находятся в node_modules рядом с полным lodash
  • … и некоторые частичные методы из lodash as отдельных зависимостей

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

Но помимо всего этого приукрашивания для полифиллов и прокладок, я считаю, что есть и другие зависимости, которые необходимы и хорошо продуманы для фактического использования основной библиотекой/инструментом, и в нашем случае это @angular/cli.

В этом нет ничего нового для JS-разработчиков, так было уже некоторое время, и с такой ситуацией нельзя мириться — размер node_modules — тема для шуток, а удаление пакетов типа «left pad» — причина катастроф.

Посмотрите историю Left Pad, если не сталкивались с ней, как один парень чуть не сломал Node.js и Babel с помощью 11 строк JS-кода здесь.

Итак, как это можно исправить?

Решение, обсуждавшееся на Hackernoon, применимо к небольшим JS-проектам и вещам в виде предоставления надлежащей стандартной библиотеки, которая решит проблему определения размера node_modules, где правильная разработка всех необходимых матриц такие как содержащие множество общих методов для компенсации текста, чисел, коллекций и других функций, которые в том же случае не понадобятся 99% других библиотек. Но вопрос, который можно задать другому, заключается в следующем: Выполнимо ли это?

Для начала было бы здорово взять за основу некоторые из упомянутых библиотек utils и объединить их с другими.

Но я считаю, что для того, чтобы это произошло, во-первых, должен быть парень, чтобы объединить все это в одну библиотеку, и во-вторых, что парень должен знать все подробности того, что объединяется в то, что так что никаких компромиссов не соблюдается, когда правильный синдикат кода формируется одним великим разработчиком, который является парнем, который будет склеивать все логическим образом. Итак, мой вопрос: легко ли найти этого парня? Я действительно так не думаю 😂 формально мир, в котором мы живем, не является односторонним. Если бы человечество было односторонним, мы бы все равно программировали наши требования из таких библиотек, как jQuery или loadash и т. д.

Интересный факт о jQuery заключается в том, что пару лет назад jQuery был почти в каждом проекте. Это произошло по довольно веским причинам, по которым люди все еще придерживаются этого, например

  • Предоставляет набор часто используемых функций в удобной для использования форме. Методы jQuery легко соединялись друг с другом (в результате разработки одной организацией).
  • Он был широко известен всем, поэтому присоединиться к проекту было легко, так как не требовалось дополнительного обучения.
  • Хотя некоторые люди жаловались на размер jQuery, в основном это было неважно, поскольку он часто загружался из CDN — поэтому в течение 90% времени он уже присутствовал на компьютере пользователя.

Последний пункт очень важен там, где на самом деле не имеет значения, насколько велика какая-то библиотека, если вам не нужно ее скачивать. Я думаю о lodash, у него действительно масса функций, которые могут заменить множество ненужных зависимостей. Благодаря своей модульной структуре и отсутствию зависимостей это отличная библиотека, которую можно выбрать, если вам нужно что-то, чего нет в JavaScript.

Я верю, что изображение выше говорит за всех нас. В мире, в котором мы живем, худший совет, который мы можем дать кому-либо, звучит так: «Если это не сломано, не чини это», и, по правде говоря, в большинстве случаев то, что не сломано, не будет также исправлено в ближайшее время. Как упоминалось выше, создание стандартной библиотеки JS могло бы помочь, но, тем не менее, участие и возможности каждого человека безграничны в отношении того, для чего это может быть обнаружено.

Поэтому в этой статье я хотел подчеркнуть, что всякий раз, когда node_modules становится для вас проблемой физически или логически, и под физическим я имел в виду, когда папка node_modules начинает занимать место на вашем диске и еще что-то, подумайте еще раз, заложили ли вы задел по этой теме, тем более программирование не индивидуальное соревнование. Если чего-то можно избежать с помощью библиотек, я не думаю, что это принесет какой-то вред, и все выиграют от кризиса node_modules.

Боковое примечание: если вы все еще застряли в кризисе node_modules, держитесь. Я опубликую статью о том, как мы можем изолировать node_modules и использовать их с точки зрения контейнеризации, в основном говоря о Docker. Пусть это временно поможет любому разработчику оптимизировать пользовательский опыт и меньше плакать, уделяя время заботе о node_modules.

До следующего раза.