4. Уроки Node.js. Структура Пакета NPM

0

0

By Pavel Bragin Following Unfollow Follow   5,839 September 7, 2016 Following Unfollow Follow

Category:

Programming

Продолжаем наш разговор об NPM.Для того чтобы посмотреть на реальный package.json поставим модуль express. Введем в консоли:

npm i [email protected]

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

Мы кратко пройдемся по некоторым особенностям package.json пока что в общих чертах, в дальнейшем, когда мы будем делать конкретные вещи, то используем это для решения конкретных задач. Итак, поля.

«name» – имя, это мы уже знаем;

«description» – информационное описание, по нему осуществляется поиск при npm search;

«version» – версия, имеет вид MAJOR, MINOR, PATCH и подчиняется спецификации semver(http://semver.org/). Что это значит? Это означает то, что когда я делаю пакет, пока его еще не опубликовал или опубликовал, но он еще в незаконченном виде, я делаю первый номер «0». Это значит, что какие бы номера версии здесь не были, я могу менять в любой момент что угодно. 0 – это нестабильный пакет. Когда пакет стал стабильным, то теперь каждый номер версии уже имеет конкретный смысл. Здесь последнее значение – это PATCH, если я вношу какие-нибудь незначительные изменения (например bugfixes), я могу менять последний номер. То есть, те люди, которые используют мой модуль, могут без проблем обновиться, при условии, что последнее число другое.

Средний компонент – это минорная версия. Она обновляется при изменениях, которые, например, добавляют новые возможности, но при этом не ломают то, что есть. Таким образом, если человек использует мой модуль, то при выпуске новой версии, например, «1.2.0» он может на нее обновиться, и текущий код не должен сломаться.

И, наконец, MAJOR – первая версия. Если я внес хоть какое-то минимальное изменение, которое ломает существующий код, например, поменял порядок аргументов в функции, то я обязан изменить MAJOR, первую версию, будет уже «2.0.0». Вот такая, достаточно простая, схема нумераций версий. У нее есть еще ряд нюансов, если захотите подробней с ней ознакомиться, заходите на http://semver.org – семантическое версионирование, используется повсеместно  в Node.JS, и не только.

Для того, чтобы поставить конкретную версию, используют такой синтаксис: npm install [email protected]. Это будет последней версией ветки 3.0, например, 3.0.15. могу просто указать npm 3 или npm 2, и будет, соответственно, последняя версия в этой ветке. Обычно старую версию ставят либо из соображений совместимости, либо потому, что в более новой какие-то ошибки.

Иногда возникает и другая задача. Необходимо поставить самую-самую последнюю версию модуля, которая еще не была опубликована, например, потому что в ней были исправлены важные ошибки или добавлены какие-то возможности. Это очень просто, если модуль разрабатывается c использованием системы версионирования Git, например, на GitHub. Достаточно получить Git Read-Only url, скопировать его и в consoel набираю

npm install

и этот url. Оно все скачает и поставит так же, как делается обычно, то есть node_modules expres. Разницы мы никакой не заметим.

Еще один вариант – это скачать готовый архив с модулем и дать его аргументам  npm install. Более подробно про npm install можно посмотреть в help. Там показано все, что может получать эта команда. То есть, npm install – очень гибкая штука, она может ставить модуль откуда угодно.

Следующие информационные поля:

«author» – про автора;

«contributors» – про тех, кто принимал участие;

«dependencies» – структурное поле, которое указывает те модули, от которых зависят данные. Если мы обратим внимание на консоль, то там, когда ставился express, выдало много подмодулей. Каждый модуль из списка в package.json этого структурного поля будет ставиться в поддиректорию node_modules. Это очень классное свойство NPM, потому что, представьте себе, мы поставили express, и он требует модуль

«connect»:»2.7.11»

И поставили еще какой-нибудь модуль сюда, который требует версию «connect» вообще другую, скажем, «3.0» и получится, что благодаря тому, что каждый модуль задает свой  »dependencies» отдельно в своем package.json, в свою поддиректорию, никаких конфликтов быть не может.

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

«connect»:»2» или

«debug»:»*», или даже более сложный синтаксис:

«send»:»>=2.5»

Свойства «dependencies» также можно использовать для упрощения установки модуля. Например, я написал модуль и хочу кому-нибудь его передать. Не обязательно при помощи репозитария. Либо я куда-нибудь его скопировал, я не обязан таскать с собой всюду большую директорию  node_modules. Я просто делаю «dependencies». Дальше кто угодно, кто получил директорию с package.json, может зайти в консоль, набрать команду npm install, и оно автоматически подтянет все пакеты, которые есть в «dependencies», создаст директорию node_modules и поставит их.

Кроме «dependencies» есть еще «devDependencies». Они не ставятся, если модуль подтягивается, как зависимость. Иначе говоря, в той инсталляции, которую я только что сделал через npm install, в express поставились только вот эти модули:

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

Они будут ставиться в двух случаях. Первое, если стоит специальный флаг config (есть такая команда : npm config), и второе, если я зайду непосредственно в директорию express, то есть в node_modules/ express/ и уже в ней наберу:

npm install.

Ошибка. Оно сказало, что пакет invalid, но это понятно, потому что я написал туда комментарии :

“devDependencies”: { // npm config

Уберем их. Вот теперь все хорошо. Оно подтягивает все модули из “devDependencies”, их подмодули и ставит.

Дальнейшие поля:

Ключевые слова – информационное поле, которое используется npm search при поиске.

“repository” – это репозитарий, где находится исходники модуля, тоже информационное поле, не играет никакой существенной роли .

 “main” – следующее поле, которое задает точку входа в пакет. Обычно, когда мы подключаем какой-то модуль, например, require express, то подключается файл index.js в этой директории, но заданием поля “main” это можно поменять. Например,

“main”: “Lib/application”,

При этом при require express будет подключаться не index.js, которого может и не быть, а данный файл. Следующее поле:

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

“scripts”  – позволяет задавать команды, которые автоматически выполняются при некоторых действиях с пакетом, например, “prepublish” автоматически выполняются “prepublish” и вызывают npm prune:

 “prepublish”:“npm prune”,

Команду npm prune мы не проходили. Она удаляет лишние модули в node_modules, которые не перечислены в зависимостях. Если хочется более подробно познакомиться с командами, то есть:

npm help prune

либо

npm help scripts

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

Итак, у нас была:

1.  структура версии пакета. Ее необходимо знать, чтобы понимать на какие версии можно обновляться, а на какие нельзя;
2. зависимости: dependencies, devDependencies – используются, как правило, для распространения пакета, чтобы легко было загружать новые зависимости, либо текущие зависимости обновить. Я в dependencies или в devDependencies могу написать нужные версии;
3. точка входа в модуль: main. Как правило, по умолчанию это index.js. Ее иногда меняют;
4. bin, scripts – тоже используются. Мы еще вернемся к ним далее. В package.json есть еще много полей, большинство из них информационные. Наиболее подробную информацию о них вы можете получить, используяnpm help json.

Материал урока взят из следующего скринкаста

We are looking forward to meeting you on our website soshace.com

About the author

Pavel Bragin

Registered 20-10-2015 | Last seen long time ago 1

0 Comments | 86 Publications