Руководство по npm: диспетчер пакетов Node.js

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

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

Войдите в диспетчер пакетов Node (npm) — диспетчер пакетов JavaScript, который чаще всего используется в сочетании с Node.js, хотя его также можно использовать независимо. Это дает вам исключительный контроль над зависимостями вашего проекта и предоставляет отличный способ внести свой вклад в мир открытого исходного кода.

Вы можете начать, просто запустив npm install <package name> и внедрив его в свой файл JavaScript.

Хотите установить конкретную версию? Без проблем. Запустите npm install <package name>@1.2.3 .

Хотите установить пакет глобально (например, Mocha или Angular-CLI)? Просто добавьте -g вот так: npm install -g angular-cli mocha .

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

CLI-команды

CLI — это то место, где пользователи проводят большую часть своего времени, взаимодействуя с npm, и его справочный интерфейс действительно полезен.

Запрос справки ( npm help ) выдает целый набор параметров, а запуск npm help-search <searchText> дает вам список результатов поиска прямо из уценки npm.

Вот основные команды, которые выделяются.

• install : он упоминается здесь из-за его крайней необходимости при работе с npm. Используется для установки нового пакета локально или глобально (при добавлении -g ) или для установки зависимостей, перечисленных в файле package.json (подробнее об этом позже).

• uninstall : это также важно. Он используется для очистки определенного пакета из каталога node_modules либо локально, либо глобально (при добавлении -g ).

• access : это игровая площадка администраторов разрешений пользователей npm в контексте npm-organizations и ограниченных (частных) пакетов. Серьезно мощная штука. При использовании в сочетании с adduser , owner , team и т. д. он обеспечивает детальный контроль над тем, кто и к чему имеет доступ.

• bin : Где устанавливаются пакеты? Запустите эту команду, чтобы увидеть абсолютный путь к файлу.

• cache : если вы начинаете устанавливать пакеты из npm слева, справа и по центру, эта команда весьма полезна. Либо вызовите его с помощью подкоманды ls , чтобы просмотреть список локально кэшированных пакетов, либо с помощью подкоманды clean , чтобы очистить все пакеты, находящиеся в кеше. Раньше, когда реестр npm был немного нестабилен, это было важно, чтобы вернуться в стабильную среду или сбросить настройки, если вы неправильно настроили разрешения npm.

• config : мы рассмотрим различные параметры конфигурации позже, но эта команда в основном имеет дело с сохранением свойств конфигурации в локальном или глобальном файле конфигурации с помощью подкоманд set , get или delete .

• dedupe или ddp : при длительной работе над проектом и установке пакетов прямо из npm эта команда просматривает локальное дерево пакетов и пытается упростить зависимости.

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

• ls : используется для визуализации зависимостей пакетов и их зависимостей в древовидной структуре. Это здорово видеть, а также полезно для сравнения с другими проектами.

• outdated : используется для оценки текущего состояния установленных зависимостей и определения того, устарели ли они. В проектах, где список корневых зависимостей состоит из сотен строк, ручная проверка пакетов почти невозможна. Добавление -g --depth=0 к этой команде позволяет вам также проверять глобально установленные пакеты.

• publish : эта команда необходима при разработке собственного пакета для npm. Он делает именно то, что следует из названия; он публикует ваш пакет в реестре npm.

• search : Используйте это для поиска в реестре всех пакетов, содержащих текст, указанный в третьем аргументе.

• shrinkwrap : Короче говоря, эта команда позволяет вам заблокировать определенные версии зависимостей в пакете по порядку, чтобы нестрогий номер semver (семантическое управление версиями) не нарушал производственный код.

• star : Вам действительно нравится пакет, который вы используете? Используйте эту команду, чтобы выразить свою признательность прямо из терминала, что затем отразится на странице пакета в реестре npm.

• update : Обычно это следует за командой outdated для обновления любых устаревших пакетов.

• version : это дает вам сокращение для изменения свойства версии package.json и добавления тега git одновременно.

Обратите внимание, что большинство этих команд могут принимать подкоманды и/или конфигурации, и этот список ни в коем случае не является исчерпывающим обсуждением CLI.

npm-конфигурация

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

Конфигурация через CLI и переменные окружения

Во-первых, конфигурацию можно задать через интерфейс командной строки с терминала.

Обычно это выглядит примерно так: npm <command> --<configuration option> [<optional value>] .

Если значение не указано, по умолчанию для параметра будет установлено значение true.

Например, предположим, что вы работаете над ограниченным (частным) пакетом npm и решили опубликовать его как общедоступный пакет.

Это легко сделать, добавив --access=public к вашей команде publish . Если бы мы не указали свойство как общедоступное, по умолчанию оно было бы ограниченным (частным).

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

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

Любая переменная среды, установленная с префиксом npm_config_ , будет использоваться для настройки npm.

Например: export npm_config_registry=localhost:4321 установит параметр конфигурации реестра глобально, и при выполнении npm будет использоваться реестр npm, расположенный на локальном хосте на порту 4321.

Конфигурация через файл npmrc

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

• Уровень проекта: в корне кода проекта вместе с его файлом package.json , обычно path/to/project/.npmrc
• Уровень пользователя: каталог, в котором настраивается учетная запись определенного пользователя, обычно ~/.npmrc
• Глобальный уровень: каталог, в котором npm ищет глобальные конфигурации, обычно $PREFIX/etc/npmrc
• Встроенный уровень: Будьте осторожны. Эта конфигурация не только глобальна, но и является частью исходного кода npm, и передовая практика рекомендует (фактически требует) не изменять код, за обслуживание которого мы не несем ответственности. Обычно его можно найти в /path/to/npm/npmrc .

Параметры конфигурации в файле .npmrc можно изменить и сохранить с помощью интерфейса командной строки, выполнив команду в следующем формате: npm config set <key> <value> .

Например, вы можете запустить npm config set access public , чтобы сделать конфигурацию публикации ограниченного (частного) пакета постоянно общедоступной.

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

Если необходима сохраняемая конфигурация на уровне проекта или на встроенном уровне, файл .npmrc необходимо изменить с помощью текстового редактора.

Конфигурация через package.json

Наконец, конфигурацию можно установить из файла package.json . Однако это редко используется (и должно использоваться только в случае явного требования), поскольку файл .npmrc уровня проекта обычно является предпочтительным местом для установки конфигурации пакета.

Примечательные параметры конфигурации

• access : как обсуждалось выше, он используется для установки разрешений.

• always-auth : важно отметить, что по умолчанию для этого параметра установлено значение false. Если установлено значение true, npm всегда будет требовать аутентификацию при обращении к реестру.

• ca : по умолчанию используется центр сертификации (ЦС) npm. Его можно изменить на null, чтобы разрешить доступ только известным регистраторам, или на определенный сертификат CA, чтобы предоставить доступ только этому конкретному. Этот параметр, наряду с cafile , cert и strict-ssl , используется редко, но говорит об аспектах безопасности и надежности npm, позволяя вам быть уверенным в том, что пакет, который вы устанавливаете, исходит из источника, которого вы ожидаете.

• color : по умолчанию имеет значение true, что дает вам возможность отказаться от стандартной мрачности терминала, окрашивая стандартный stdout , разрешенный дескрипторами файлов tty. Если установлено значение false, терминал остается тусклым. Когда для него установлено значение always , он всегда выводится в цвете.

• depth : этот параметр позволяет детально контролировать то, что вы видите с рекурсивными командами, такими как ls и outdated , задавая, насколько глубоко они выполняются. Значение 0 будет оценивать только первый уровень зависимостей, тогда как бесконечность (по умолчанию) приведет к оценке всех уровней зависимостей. Исключением из этого правила является использование его с outdated ; в этом случае бесконечность интерпретируется как 0, чтобы обеспечить более релевантный вывод.

• dev : по умолчанию установлено значение false, но когда для него установлено значение true (при выполнении npm install ), все зависимости разработки в файле package.json будут установлены вместе с обычными зависимостями.

• dry-run : когда для этого параметра установлено значение true, npm не будет вносить никаких изменений в ваш пакет, а вместо этого сообщит вам, что он сделал бы. Это может быть очень полезно при выполнении определенных команд, таких как dedupe или update .

  

• git-tag-version : по умолчанию установлено значение true. Этот параметр помечает версию в git при запуске команды npm version . Если вы используете npm в качестве диспетчера пакетов для большого проекта с помеченными версиями в git, это может сэкономить вам время и не забыть обновить файл package.json .

• loglevel : по умолчанию установлено значение warn , которое выдает ошибку и предупреждение при выполнении команд npm. Другие настройки включают в себя silent , который не обеспечивает вывода; error , который выводит только ошибки; http , который сообщает только об ошибках HTTP-запроса; info , для получения информативного вывода); verbose , который регистрирует почти все; и silly , который, как следует из названия, дает глупый объем вывода, а затем еще немного.

• production : когда для этого параметра установлено значение true, npm действует соответствующим образом и запускает все команды в производственном режиме. Это означает, что разработка или необязательные зависимости не будут установлены, а также не будут выполняться какие-либо задачи, связанные с разработкой.

• rollback : если установлено значение true, все неудачные установки удаляются. Это удобно, когда установка зависимостей не удалась. В зависимости от вашего уровня ведения журнала вы сможете увидеть, какие установки завершились неудачно, записать их и запустить команду npm install с параметром отката, установленным в true. Затем с помощью ваших заметок и пробной установки (как описано выше) вы сможете отладить проблему.

• save : When installing a package directly from the registry, you can append -save to the command which will add the installed package to the dependencies option in the file. For example, file. For example, npm install lodash добавит lodash к вашим зависимостям.

• save-dev : аналогично параметру сохранения конфигурации, добавьте --save-dev при установке пакета, после чего он будет добавлен к параметру devDependencies в файле package.json .

• save-optional Optional : аналогично параметру сохранения конфигурации, добавьте --save-optional при установке пакета, после чего он будет добавлен в параметр optionDependencies в файле package.json .

• save-exact : при установке пакетов опции save , save-dev и save-optional изменяют файл package.json , вставляя установленный пакет в соответствующее свойство с помощью оператора диапазона semver. При вызове параметра конфигурации save-exact со значением true в сочетании с одним из упомянутых выше параметров используется конкретный номер версии, игнорируя диапазон semver.

• save-prefix : устанавливает оператор диапазона semver при использовании save , save-dev или save-optional . По умолчанию используется ^ , что позволяет выполнять незначительные обновления пакетов при установке. Это может быть установлено для любого допустимого оператора диапазона semver с префиксом.

• tag-version-prefix : обычное значение по умолчанию — v , указывающее, что добавляется к версии тега git при запуске npm version .

Обновление npm с помощью npm

Вы также можете использовать npm для обновления самого себя.

Просто запустите npm install -g npm@latest , и npm будет обновлен до последней стабильной версии. Важно отметить, что каждая версия Node.js поставляется с определенной версией npm, и, по моему опыту, не стоит слишком сильно возиться с этой парой.

В конце концов, я рекомендую придерживаться пары, как они предназначены.

При использовании npm в качестве отдельного инструмента убедитесь, что вы понимаете последствия использования любой версии, которую вы выберете. Существует отличный инструмент для управления разными версиями Node.js (и, в свою очередь, версиями npm) в одной системе, которая называется nvm.

Файл package.json

Файл package.json — это ключевой элемент, который связывает все вместе.

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

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

Поле имени должно соответствовать определенным правилам, определенным в документации npm по именованию, а поле версии подчиняется спецификациям semver.

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

"основной"

«main» определяет точку входа в ваше приложение, по умолчанию это index.js . В зависимости от соглашения или вашего фреймворка это может быть app.js или main.js Вы, конечно, можете сделать из него все, что захотите.

«скрипты»

Это недооцененное свойство.

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

Во-вторых, он предоставляет место, где вы можете использовать псевдоним для множества часто используемых команд, начиная от задач сборки (определяемых в gulp или grunt), запуска установки других зависимостей (с чем-то вроде Bower), запуска сервера разработки с помощью веб-пакета или запуск набора команд bash.

«зависимости»

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

Это делается путем добавления --save (или сокращения -S ) в конце команды npm install .

Когда вы это сделаете, новые установленные пакеты будут добавлены в список зависимостей в вашем файле package.json .

Точно так же зависимость можно удалить, добавив --save при запуске команды npm uninstall .

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

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

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

«devDependencies»

Отдельно от свойства зависимостей свойство «devDependencies» позволяет вам определять зависимости, которые используются только на этапе разработки и не требуются для производственной сборки (например, ESLint, пакеты grunt-contrib и Protractor). Как и в случае с зависимостями, это свойство можно изменить из терминала, добавив --save-dev (или сокращение -D ) в конец команды npm install или команды npm uninstall . То же самое предостережение относится к управлению версиями, как указано в разделе о зависимостях.

мусорное ведро

Здесь вы можете указать исполняемый файл (файлы) вашего пакета, например, путь к утилите CLI. Это свойство указывает npm создавать локальные или глобальные символические ссылки на ваши исполняемые файлы, когда ваш пакет установлен.

«конфигурация»

Как обсуждалось ранее, именно здесь вы определяете параметры конфигурации в файле package.json .

"частный"

Если установлено значение true, npm откажется публиковать пакет.

Это не следует путать с настройкой конфигурации доступа.

Это удобная настройка, когда у вас есть проект, в котором используется npm вместе с его package.json , но он не предназначен для публикации в реестре npm, ни ограниченном, ни общедоступном.

Если ваше намерение изменится, просто измените настройку на false, и вы сможете опубликовать свой пакет.

Пользовательские свойства

Файл package.json также принимает настраиваемые свойства, если имя еще не определено или не зарезервировано.

Разработка собственного пакета npm

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

Скорее всего, в какой-то момент вы тоже захотите разработать свой собственный пакет для совместного использования.

Сначала нужно создать файл package.json с минимально необходимыми свойствами «имя» и «версия», а затем в свойстве «основное» указать точку входа, например index.js.

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

Пакеты могут быть общедоступными или частными.

Публичные пакеты бесплатны для публикации и доступны для всех.

Частные пакеты, называемые пакетами с областью действия, могут быть опубликованы только в том случае, если вы заплатили пользователю частных модулей, и их можно идентифицировать по отдельному @username/ , который добавляется к имени пакета.

Пакеты с заданной областью также можно опубликовать публично, вызвав команду publish с --access=public .

Кроме того, если вы потратите еще немного времени на расширение и улучшение кодовой базы вашего пакета и придет время для публикации новой версии, вы просто измените версию (в соответствии с правилами и соглашением semver) пакета в package.json . файл и введите npm publish .

Вы также можете использовать интерфейс командной строки и вызвать npm version <update_type> , где update_type — это patch , minor или major , как описано в semver, после чего автоматически увеличивается номер версии в файле package.json .

нпм Организации

Опять же, документация npm для этого превосходна, и было бы бесполезно просто повторять их слова.

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

Хотя это сложно освоить, это очень полезно.

Сила нпм

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

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

Другие интересные статьи о npm можно найти в статье Использование Scala.js с npm и Browserify.