Трудно найти разработчиков, которые не знают, что такое npm. На начало 2017 года в наличии более 350 000 уникальных модулей, поэтому это ресурс для node.js. Но npm - это лишний вес для своего возраста.

Детское ожирение - проблема… для npm

Npm растет не по дням, а по часам. Некоторый рост является здоровым, а какой-то нет. Как и ребенку, ему нужна правильная диета, состоящая из хороших практик и разработчиков, которые их применяют.

350К - это много модулей, но не слишком ли много? Сложно сказать. Существует множество уникальных случаев, когда небольшая вариация модуля лучше подходит для одного варианта использования, чем для другого. Возможно, есть место для обрезки ненужных модулей, но есть и другие вещи, которые вы можете сделать.

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

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

Вы просто…

npm install awesome-sauce

… И вы в путь! Правильно? Может быть нет.

Вы смотрели на код этого замечательного модуля, загруженный в папку вашего проекта? Смотри внимательно. Некоторые IDE скрывают папку node_modules, чтобы представить внешний вид чистого проекта. Это как черная одежда ... похудание, но все же фасад.

В npm есть много модулей с излишними «дополнениями». На собственном опыте я видел множество модулей, содержащих папки с примерами, каталоги документации и многое другое. В некоторых случаях функциональные файлы JavaScript в совокупности весят менее 100 КБ вместе с 20 МБ документации и файлов примеров.

Сообществу Node необходимо свести к минимуму занимаемые модули.

В чем разница?

Подчеркивание - популярный модуль. Согласно сегодняшней статистике, только вчера его скачали 87 920 раз. За последний месяц его скачали 4,5 миллиона раз. Это популярная зависимость. А теперь представьте, что из библиотеки было удалено 1,5 КБ (что примерно равно размеру файла README). 4,5 МБ x 1,5 КБ = ~ 6,4 ГБ / мес.

Я выбрал подчеркивание специально из-за его популярности и относительно хорошей работы по игнорированию лишних файлов, хотя на момент написания этой статьи прямая установка npm по-прежнему включает как минифицированную (16 КБ), так и неминифицированную (47 КБ) версии библиотеки, а также файлы LICENSE и README размером 2 КБ каждый.

Публикуйте только то, что вам нужно

Существует два основных подхода к минимизации занимаемой площади модуля npm. Внесение в белый список выполняется с помощью файла package.json, а в черный список - с помощью файла .npmignore.

Более тонкий выбор: добавление файлов в белый список в package.json

Внесение в белые списки - это наиболее эффективный и надежный способ сократить количество посещений npm. В разделе файлы package.json указывайте только соответствующие ресурсы.

Некоторые файлы включены всегда, независимо от настроек:

  • package.json
  • README (и его варианты)
  • CHANGELOG (и его варианты)
  • ЛИЦЕНЗИЯ / ЛИЦЕНЗИЯ

И наоборот, некоторые файлы всегда игнорируются:

  • .git
  • CVS
  • .svn
  • .hg
  • .lock-wscript
  • .wafpickle-N
  • * .swp
  • .DS_Store
  • ._*
  • npm-debug.log

Явно определяя необходимые файлы, разработчики гарантируют более компактные пакеты, даже если что-то случайно попадает в базу кода (например, каталог примеров).

Игнорируемая диета: файлы в черном списке

По иронии судьбы, Npm часто игнорирует возможность .npmignore. Если атрибут «files» package.json предназначен для внесения в белый список, то .npmignore является эквивалентом черного списка.

Этот файл похож на файл .gitignore. Это предотвращает публикацию определенных файлов и папок в реестре npm. Это просто и упрощает ваши модули. Вам следует использовать его в каждом модуле, который вы публикуете, если вы не используете белые списки.

Вот пример обычного файла игнорирования, который я использую в своих модулях:

_*
.*
*.log
*.md
*.yml
examples
docs
test

Этот файл предотвращает отправку тестов, примеров и документов. Он также предотвращает такие вещи, как конфигурации CI / CD, дополнительную уценку (помните, что README всегда включен, независимо от того, что вы делаете), надоедливые журналы разработки, такие файлы, как .gitignore, и все файлы, начинающиеся с подчеркивания. Подчеркивание - это личное соглашение, которое я использую, например каталог _todo.

Дополнительные примеры см. В моем профиле npm или в исходном коде на github.com/coreybutler.

Что ДЕЙСТВИТЕЛЬНО нужно публиковать в npm?

Для использования узла действительно необходимо иметь как минифицированные, так и неминифицированные версии файла? README действительно необходим? Сколько копий этого находится на вашем рабочем сервере? Вы запускаете свои проекты на недорогой виртуальной машине за 5 долларов или на бесплатном экземпляре OpenShift? Хотя пространство часто бывает дешевым, не злоупотребляйте им.

Некоторые файлы удобны, но я утверждаю, что люди даже не смотрят на содержимое пакета. Когда они это делают, они обычно просматривают его на Github. Если кто-то пытается создать большой объем документации, сделайте последний шаг и опубликуйте его как страницу Github или создайте вики. Просто убери это из npm.

Cutting the Cruft

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

Любой точечный файл (.gitignore, .jshintrc, .editorconfig и т. д.)

Хотя это обычно очень маленькие файлы, они обычно не придают функциональной ценности опубликованному модулю. Их легко удалить одним махом, добавив в .npmignore следующее:

.*

Любой файл Markdown

Опять же, эти файлы обычно не имеют функциональной ценности для модуля. Вместо этого разместите их на странице / вики Github. Это включает в себя содержимое большого файла README, СОСТАВЛЯЮЩИЙ / ДОПОЛНИТЕЛЬНО и т. Д.

Файл лицензии?

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

GOTCHA!

Помните, что npm будет включать определенные файлы независимо от того, игнорируются ли они. Сюда входят ЛИЦЕНЗИЯ, README и CHANGELOG (и варианты). Единственный реальный вариант - вообще не иметь этих файлов или уменьшить их содержимое. Например, вместо добавления содержимого в README предоставьте ссылку на вики / страницу Github. Это позор, поскольку такие сайты, как Github, автоматически делают так много приятных вещей с помощью README, но многие серверы загромождены этим совершенно ненужным дополнением к производственной среде.

Модульные тесты

Разработчики иногда думают, что люди запускают свои тщательно продуманные наборы тестов, но на самом деле они даже не подозревают о существовании тестов. Забота о существовании тестов еще менее вероятно. Большинство разработчиков запускают набор тестов только тогда, когда возникает проблема. Менее опытные / терпеливые разработчики откажутся от вашего модуля в пользу другого, работающего так, как они ожидают. Если их действительно интересуют модульные тесты, они будут проверять ваш репозиторий Github или состояние вашей службы CI. Вы ведь используете CI?

Если вы не используете Travis или другой сервис для своих модулей с открытым исходным кодом, вам стоит взглянуть. Travis, Shippable, CodeShip, AppVeyor и другие предлагают бесплатные услуги CI для проектов с открытым исходным кодом.

Поскольку вы являетесь ответственным разработчиком, использующим службу CI, вам следует добавить эти файлы конфигурации в .npmignore, например файлы .yml или .yaml.

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

Примеры и документация

Многие люди создают папку «Примеры», чтобы продемонстрировать, как использовать модуль. Опять же, обычный рабочий процесс среднего разработчика обычно не включает запуск примеров из развертывания npm. Они посетят общедоступную страницу (Github / BitBucket / Whatever) за помощью. Как и тесты, если они хотят запустить примеры, они клонируют проект.

Файлы проекта и редактора

Никакие другие файлы, относящиеся к проекту / редактору, не нужно развертывать в npm. Сюда входят файлы сборки. В модуле может быть замечательный процесс grunt или gulp для оптимизации чего-либо, но если вы не распространяете плагин grunt / gulp, вам не нужно включать эти файлы в свой пакет npm.

Исключения из правила

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

Обрезка цепочек жировой зависимости

До сих пор эта статья была сосредоточена в основном на удалении ненужных файлов из опубликованных модулей npm. Это меньшее, что могут сделать разработчики. Есть и другие «упражнения», чтобы укрепить модули.

Цепочки зависимостей могут быть довольно длинными. Некоторым бывает так долго. Пользователи Windows получают сообщение об ошибке «слишком длинный путь» при попытке их удаления. Это смешно. Если не считать операционных систем, если вам нужно устранить неполадки в глубоко вложенном модуле в каталоге node_modules, это немного болезненно.

Цепочки зависимостей можно упростить с помощью процесса выравнивания. Эта концепция означает перемещение модуля «вверх по цепочке». Например, рассмотрите следующую цепочку зависимостей node_modules:

node_modules
  module-a
    module-b
      module-c
        module-d
  module-e
    module-b
      module-c
        module-d
    module-f
  module-g
    module-b
      module-c
        module-d
  module-h
    module-b
      module-c
        module-d

Модуль «B» зависит от «C», который зависит от «D». Модули E / G / H также зависят от модуля «B» и всей цепочки зависимостей. Эту цепь следует сгладить, перемещая модуль «B» вверх, в результате чего:

node_modules
  module-a
  module-e
    module-f
  module-g
  module-h
  module-b
    module-c
      module-d

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

ОБНОВЛЕНИЕ: есть инструменты для сглаживания цепочек зависимостей, например npm-dedupe.

Опыт разработчика

Некоторые люди считают, что простая публикация модуля в npm привлечет участников и поможет их проекту процветать. Не совсем. Это обсуждение легко могло бы быть совершенно другой статьей, но если вы в конечном итоге ищете участников, их легче привлечь с помощью бережливых модулей. Структура кода должна быть понятной, экономичной и не требовать поиска через гору зависимостей.

Удачных публикаций, и давайте сделаем npm подходящим для всех нас! Теперь мне нужно очистить некоторые из моих модулей :-)