Как опубликовать пакет в npm
Перейти к содержимому

Как опубликовать пакет в npm

  • автор:

Как опубликовать пакет в NPM

Подробная инструкция по публикации, обновлению, удалению и установке ваших пакетов в Node Package Manager.

Дата публикации
28 Февраля 2021
Дата изменения
8 Марта 2021
Уникальных просмотров

Оглавление

  • Что нужно для работы с NPM
  • Инициализация NPM-пакета
    • package.json
    • README.md
    • npm version patch
    • npm version minor
    • npm version major

    Для начала нужно ответить на вопрос — зачем вам вообще использовать NPM? Ответ очень просто, вы можете написать некий плагин, компонент или скрипт и таскать его из проекта в проект. Если вдруг вы обнаружите ошибку или захотите улучшить ваше творение, вам придется во всех проектах ручками править код. Этого можно избежать, добавив ваше творение как отдельный пакет в NPM и подключать / обновлять его одной командой на всех ваших проектах.

    Что нужно для работы с NPM?

    Чтобы создать NPM-пакет у вас должен быть установлен Node.js. После установки Node.js, нужно убедиться что установка прошла корректно и заодно проверить его версию, сделать это можно следующей командой:

    npm -v

    Инициализация NPM-пакета

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

    npm init

    Вам будут заданы вопросы про ваш NPM-пакет, вы можете ответить на них сразу или пропустить, нажав Enter. После ответов на вопросы, в директории пакета создаться файл package.json , в нем будет прописана основная информация о вашем пакете.

    package.json

    Вы можете редактировать файл package.json вручную. Вот основные и самые важные его настройки:

    • name — Имя, по которому пакет будет доступен в NPM.
    • description — Описание пакета.
    • author — Автор пакета.
    • license — Лицензия распространения пакета.
    • version — Версия пакет (будет сгенерирована автоматически).

    Перед тем как создавать пакет, убедитесь что такого названия в базе NPM еще нету. Для этого воспользуйтесь поиском на сайте, вбейте название которое придумали и проверье уникальность.

    README.md

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

    Пример README.md можете взять отсюда.

    Публикация NPM-пакета

    Для начала нужно пройти регистрацию на npmjs.com, сделать это можно из терминала командой:

    npm adduser

    Если же учетная запись у вас уже есть, то нужно авторизироваться в терминале:

    npm login

    Проверить под какой учетной записью вы находитесь можно с помощью команды:

    npm whoami

    Теперь можно публиковать NPM-пакет:

    npm publish

    После введения команды выше, ваш пакет отправиться на сервера NPM и будет доступен для подключения к проектам.

    Обновление NPM-пакета

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

    1. Внести изменения в код.
    2. Обновить версию пакета командой npm version [ major | minor | patch ] .
    3. Опубликовать новую версию пакета командой npm publish .

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

    npm version patch

    Команда npm version patch , увеличит версию пакета например, с 1.0.0 до 1.0.1. Незначительные исправления мелких ошибок.

    npm version minor

    Команда npm version minor , увеличит версию пакета например, с 1.0.0 до 1.1.0. Добавления нового функционала, который не влияет на уже существующий функционал.

    npm version major

    Команда npm version major , увеличит версию пакета например, с 1.0.0 до 2.0.0. Модификация пакета без обратной совместимости с предыдущей версией. Разработчик поймет что простое обновление пакета может что-то сломать и изучит вопрос правильного обновления на новую мажорную версию.

    Удаление NPM-пакета

    Удаление NPM-пакетов является очень плохим тоном, т. к. от этих пакетов могут зависеть проекты других пользователей. Однако, если после публикации пакета командой npm publish прошло менее 24 часов, то публикацию можно отменить командой npm unpublish . Пакеты, которые были добавлены более 24 часов назад, удалить нельзя.

    Если все-таки вам необходимо удалить пакета, то напишите в поддержку, указав причину удаления пакета. Пакет будет помечен как @deprecated и исчезнет из вашего профиля.

    Установка NPM-пакета

    После того, как ваш NPM-пакет появился в вашем профиле, он будет доступен по ссылку:

    https://www.npmjs.com/package/название-вашего-пакета

    И его можно будет подключить к любому вашему проекту, с помощью команды:

    npm i название-вашего-пакета

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

    Благодарность автору

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

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

    Публикация пакета в npm

    Polina Shneider

    Представьте ситуацию, что в вашем проекте есть JavaScript-модуль, и нужно скопировать его в другой проект. Есть вариант перенести код вручную, а можно подключить отдельным компонентом, и сделать это всего одной строчкой при помощи npm — менеджера пакетов для Node.js. В этой статье вы узнаете, как оформить ваш модуль в виде пакета, разместить его в общедоступной базе и поддерживать в дальнейшем.

    Подготовительный этап

    Для создания npm-пакета у вас должен быть установлен Node.js. После установки Node.js с официального сайта, npm в вашей системе появится автоматически.

    Убедимся, что npm установлен — проверим его версию, набрав в консоли:

    Удобно хранить репозиторий на каком-нибудь хостинге совместной разработки IT-проектов, например, на GitHub. Тогда вы сможете:

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

    В терминале переместимся в директорию проекта и выполним в ней команду:

    Вам будут заданы вопросы об основных параметрах пакета. Можете заполнить их сразу в консоли или временно пропустить, нажимая Enter, и потом сделать это в текстовом редакторе. В текущей директории появится файл package.json.

    Package.json

    Параметры пакета можно отредактировать напрямую в файле package.json:

    • ‘name’— имя, по которому пакет будет доступен в npm
    • ‘description’— описание пакета
    • ‘author’— никнейм и ссылка на разработчика, например, на гитхабе, либо ‘contributors’— когда в разработке принимало участие несколько человек
    • ‘license’ — лицензия

    Поля ‘version’, ‘repository’, ‘bugs’, ‘homepage’ будут сгенерированы автоматически при создании package.json.

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

    В секцию scripts можно поместить ваши команды, которые должны выполняться Node.js. Например, запуск системы сборки или тестов. Это словарь, заполняемый в формате ключ_команды : выполняемый скрипт.

    Чтобы запустить скрипт, достаточно вызвать в консоли:

    npm run ключ_команды

    При запуске npm run build будет выполнено: webpack —progress —display-error-details —display-entrypoints —display-reasons

    Добавление скриптов позволит вам вызывать серию команд по одному ключевому слову.

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

    README

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

    Публикация в npm

    Если вы не зарегистрированы на npmjs.com — сделайте это с помощью команды:

    npm adduser

    Если же у вас есть учётная запись — вы можете авторизоваться:

    Вас попросят ввести логин и пароль.

    После ввода следующей команды ваш пакет окажется в npm, поэтому важно ещё раз всё проверить и убедиться в работоспособности модуля. Проверили? Отлично, публикуем 🙂

    Наберите в консоли:

    npm publish

    Если публикация прошла успешно, можно перейти по ссылке и увидеть информацию о пакете:

    https://npmjs.com/package/<your_package_name>

    Также он появится у вас в профиле на сайте.

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

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

    Обратите внимание: пакеты, публикуемые от имени команды, по умолчанию private. Чтобы сделать ваш пакет общедоступным, выполните публикацию с ключом —access public:

    npm publish —access public

    Установка пакета

    Наконец, когда пакет опубликован, его можно установить и подключить в любом проекте с помощью команды:

    npm install mypackage

    В JavaScript-файле, где вы хотите использовать модуль, пропишите:

    import mypackage from ‘mypackage’;

    Готово, теперь вы можете обращаться к модулю по имени. Например, для вызова метода init:

    mypackage.init();

    Обновление пакета

    Что нужно сделать, чтобы обновить модуль?

    1. Внести изменения в код.
    2. Обновить версию: npm version [ major | minor | patch ]
    3. В терминале ввести npm publish

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

    Если изменения незначительные (исправления мелких ошибок) — npm version patch. Это увеличит версию package.json, например, с 1.0.0 до 1.0.1

    Если в пакете появились новые методы, не влияющие на уже существующие, то npm version minor и изменение второго знака: 1.0.0 —> 1.1.0

    В случае модификации кода без обратной совместимости с предыдущей версией, npm version major — то, что вам нужно. И увеличение версии: 1.0.0 —> 2.0.0

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

    Важно: если вы решили изменить версию в package.json вручную, то пропустите этот пункт, иначе версия будет изменена дважды.

    Удаление пакетов из npm

    Начнем с того, что удаление пакетов считается плохой практикой — от них могут зависеть проекты других пользователей. Однако, если вы опубликовали пакет командой npm publish, и поняли, что что-то пошло не так, отменить это действие в течение 24 часов можно командой npm unpublish. Npm запретил самостоятельно удалять пакеты, которые старше суток.

    Если удалить такой пакет всё же необходимо, напишите в поддержку, указав причину. Пакет будет помечен как @deprecated и исчезнет из вашего профиля. Npm предупреждает о невозможности публикации нового пакета, если его название и версия будут совпадать с удаленным. Но есть и хорошие новости — пакет можно опубликовать повторно, изменив номер версии 🙂

    Итого

    Публикация в npm позволяет подключать модули отдельными компонентами. А семантическое версионирование пакетов помогает пользователям понимать совместимость релизов друг с другом.

    Полезные ссылки

    1. Небольшой видео-гайд по публикации в npm
    2. Как собрать пакет npm

    If you like this article, share a link with your friends

    Read more

    We talk about interesting technologies and share our experience of using them.

    Публикация NPM-пакетов

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

    1. Создание проекта

    Я предпочитаю по возможности брать готовые инструменты, а не изобретать велосипед. Поэтому использую стандартный Create React App . Для поднятия проекта, который будет написан на TypeScript, следует использовать команду:

    npx create-react-app my-app --template typescript

    Созданный проект будет полностью сконфигурирован для работы с TypeScript.

    2. Подготовка структуры проекта

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

    src App.css App.tsx index.css index.tsx

    Файлы react-app-env.d.ts , reportWebVitals.ts и setupTests.ts не трогаю.

    Файлы библиотеки расположим в каталоге src/lib , структура которого будет следующей:

    src lib components tests index.css index.ts

    Тут все очевидно: компоненты располагаем в components , тесты в tests , точка входа в библиотеку будет в index.ts , стили в index.css .

    3. Подготовка package.json

    Из коробки Create React App создает минималистичный package.json. Для публикации его необходимо дополнить:

    • name — указать реальное название пакета (а не название приложения). Мне лень искать адекватное название в общем пространстве имен, поэтому я использую собственный скоп: @alxgrn/react-form .
    • description — описание.
    • private — надо поставить в false .
    • author — укажем автора, пусть все знают!
    • license — указать лицензию. Я выбрал Apache-2.0 . Название надо указывать в правильном формате, если сомневаетесь, потренируйтесь с использованием команды npm init , она умеет проверять.
    • keywords — массив ключевых слов для облегчения поиска пакета.
    • main и module — точка входа в библиотеку. Мы будем располагать готовые файлы в каталоге dist с точкой входа dist/index.js . Надо отметить что поле module отсутствует в документации, но повсеместно используется. Зачем оно нужно при наличии main — загадка, которую лень разгадывать, поэтому просто напишем и все.
    • files — массив файлов, которые будем публиковать. Мы указываем каталог dist , куда сложим готовый проект. По умолчанию также будут добавлены README и LICENSE , причем с любыми расширениями и регистром.
    • homepage , repository , bugs — тут все понятно.

    ВАЖНО: После того как вы укажете в homepage что-то типа:

    "homepage": "https://github.com/alxgrn/react-form#readme",

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

    "start": "PUBLIC_URL=/ react-scripts start",

    4. Установка и настройка babel

    Обидно осознавать что Create React App умеет делать все, что нам надо для сборки проекта, но делает это где-то у себя внутри по своим правилам, в которые нас не особо посвящает. Было бы здорово, если бы он умел сразу готовить проект к публикации, но нет, так нет. Будем сами.

    Для преобразования TypeScript в JavaScript, который затем перегоним в «древний» JavaScript мы будем использовать babel. Установим его в проект:

    npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-react @babel/preset-typescript

    Сконфигурируем babel создав в корне файл babel.config.json с следующим содержанием:

     < "comments": false, "presets": [ [ "@babel/preset-env", < "targets": ">0.25%, not dead", "useBuiltIns": "usage", "corejs": "3.6.5" > ], "@babel/preset-react", "@babel/preset-typescript" ], "ignore": [ "**/tests", "**/*.d.ts" ] >

    Мы удаляем из результата комментарии, игнорируем файлы тестов (которые будем держать в каталоге src/lib/tests ) и объявления типов (о которых ниже).

    Теперь добавим в раздел scripts в файле package.json команду для запуска билда:

    "build:js": "rm -rf dist && NODE_ENV=production babel src/lib --out-dir dist --copy-files --extensions \".ts,.tsx\" --source-maps true"

    Как уже отмечалось ранее, мы будем складывать результат сборки в каталог dist в корне проекта. Поэтому первое что делает этот скрипт — удаляет предыдущую сборку. Затем он устанавливает переменную среды окружения в продакшен режим и запускает babel. Babel будет искать для обработки файлы с расширениями .ts,.tsx (кроме тех что указали в блоке ignore в файле конфигурации) в каталоге src/lib , а результат записывать в каталог dist . Необработанные файлы будут просто скопированы в dist . Также будут созданы файлы с sourcemap.

    5. Генерация файлов объявления типов

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

    На предыдущем шаге мы уже сказали babel не обрабатывать эти файлы, а просто скопировать в папку dist . Теперь осталось их сгенерировать. Так как мы использовали Create React App у нас уже есть компилятор tsc, поэтому просто воспользуемся им. Добавим в раздел scripts файла package.json следующую команду:

    "build:types": "./node_modules/.bin/tsc --project ./tsconfig.types.json",

    Обратите внимание на то, что мы указываем компилятору использовать файл проекта tsconfig.types.json . Мы не можем использовать файл tsconfig.json , который для нас создал Create React App т.к. в нем установлен флаг noEmit , который не совместим с нужным нам флагом emitDeclarationOnly .

    Поэтому мы просто копируем файл tsconfig.json в tsconfig.types.json , затем в блоке compilerOptions добавляем «declaration»:true и «emitDeclarationOnly»: true , а «noEmit»: true , наоборот, убираем.

    Дополнительно мы меняем в блоке include каталог на src/lib , так как нас интересует только он.

    Теперь при запуске команды

    npm run build:types

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

    6. Добавим команду сборки

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

    "build:dist": "npm run build:types && npm run build:js && rm -rf dist/tests",

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

    7. Работа с зависимостями

    Вернемся к файлу package.json . В нем присутствуют две секции dependencies и devDependencies . В первом перечислены зависимости, которые требуются для работы пакета в продакшене, во втором — только во время разработки.

    Это все прекрасно пока мы создаем приложение, но когда мы пишем библиотеку, мы должны учитывать что она будет помещена в целевой проект. В нем скорее всего уже будут установлены зависимости, которые мы тоже используем. Уж точно там будет установлен react коль скоро мы пишем библиотеку react-компонентов. Не обязательно, но возможно, что и другие компоненты тоже уже будут установлены. Если мы оставим эти зависимости внутри своего dependencies , могут возникнуть всякие неприятности типа использования двух реактов в одном приложении. Нам такое не надо. Поэтому я перенес все зависимости из dependencies в devDependencies , а те, которые нам нужны для продакшена в peerDependencies :

    "peerDependencies":

    Как видите, помимо реакта мне нужен пакет react-children-utilities .

    После этих изменений полезно будет запустить

    npm install

    8. Публикация пакета

    Теперь все готово к публикации пакета. Но есть несколько нюансов.

    8.1. Я решил использовать в названии пакета имя своего аккаунта т.е. в терминологии npm у меня scoped package . По умолчанию такие пакеты считаются приватными и для их публикации в первый раз надо использовать специальный флаг:

    npm publish --access public

    В дальнейшем можно запускать команду без этого флага.

    8.2. Прежде чем реально публиковать пакет, неплохо было бы его протестировать. Для этого можно использовать команду «npm link» . Но надо быть готовым к тому что всплывет ошибка связанная с Duplicate React.

    8.3. Перед очередной публикацией необходимо изменить версию пакета. Можно это делать руками, а можно использовать команду «npm version» .

    9. Плюшки

    После публикации захочется плюшек.

    9.1. Покрытие тестами

    Чтобы coverage тестов считался только в каталоге библиотеки, надо добавить в pakage.json настройку для jest :

    "jest": < "collectCoverageFrom": [ "src/lib/**/*." ] >
    9.2. Беджики в README.md

    Беджиков много, их почему-то все любят. Брать можно на shields.io. Для текущей версии и типа лицензии можно взять сразу.

    Для беджика прохождения билда можно настроить Action «Node.js CI» на GitHub . В неё же можно сразу добавить интеграцию с codecov.io для вывода беджика покрытия тестами. Codecov , в отличии от Travis CI , не просит вводить данные карты для открытых проектов.

    10. Вот и всё

    Надеюсь кому-то будет полезно.

    Как опубликовать собственный NPM-пакет

    Перевод статьи «Publish your own NPM package».

    Название статьи может показаться пугающим. Для меня самого так и было. Но я покажу вам, что бояться здесь нечего. Опубликовать свой первый NPM-проект — просто интересный опыт.

    Если вас в принципе заинтересовала эта статья, значит, вы по крайней мере слыхали об NPM и, вероятно, пользовались им ранее.

    Просто короткое напоминание: NPM — это самый крупный реестр программного обеспечения, а также менеджер пакетов и установщик.

    Хотите узнать, как установить NPM? Собственно, он поставляется в комплекте с Node. Если хотите узнать, как установить Node, загляните на Homebrew.

    Для чего вам может понадобиться публиковать NPM-пакет?

    Допустим, вы создали что-то, чем сами постоянно пользуетесь в своих проектах. Тогда, вероятно, вы уже поняли, какая это головная боль — обновлять этот код повсюду. А вот если вы опубликуете этот код в виде NPM-пакета, вы сможете вносить изменения во все свои проекты, где он используется, при помощи команды npm-update.

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

    Как создать собственный NPM-пакет

    Начнем с самого начала.

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

    mkdir astro-static-tweet && cd astro-static-tweet

    Затем инициализируем NPM.

    npm init

    По ходу дела отвечайте на вопросы, которые будут появляться на экране.

    Что касается имени пакета, можно использовать публичное имя типа my-plugin , но велика вероятность, что кто-то его уже занял. Проверить, доступно ли выбранное вами имя, можно при помощи команды npm search .

    Второй вариант — опубликовать пакет, перед именем которого будет идти ваше имя. То есть у вас получится что-то вроде @username/my-plugin . Скорее всего, такое имя будет уникальным.

    Пишем код

    Теперь давайте создадим какой-то код, чтобы наш плагин что-то делал.

    Сделаем суперпростой пример: код в нашем пакете будет всего лишь выполнять базовые математические действия.

    Создаем файл index.js и добавляем в него следующий код:

    function add(one, two) < return one + two; >module.exports = add;

    Поскольку мы хотим использовать этот пакет в дальнейшем, мы можем затребовать функцию add :

    const add = require('plugin-name'); console.log(add(2, 5));
    Добавление нескольких функций

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

    function add(one, two) < return one + two; >function subtract(one, two) < return one - two; >function multiply(one, two) < return one * two; >module.exports = ;

    После загрузки нашего пакета мы сможем импортировать эти функции:

    const = require('plugin-name');
    Добавление README

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

    • инструкции по установке
    • пример использования
    • указания, как сообщать о проблемах.
    • над чем вы еще работаете
    • лицензия
    • руководство для потенциальных контрибьюторов.

    Тестируем наш пакет

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

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

    Мы можем протестировать наш пакет даже до того, как он будет опубликован в NPM-реестре. Для этого нужно подключить его локально.

    Перейдите в папку пакета и выполните следующую команду:

    npm link

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

    npm link имя-вашего-пакета

    Если все работает хорошо, переходим к следующему шагу.

    Публикация NPM-пакета

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

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

    npm login

    Следуйте шагам, которые будет предлагать скрипт.

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

    npm publish

    Вы использовали в имени пакета свое имя ( @username/my-package )? Тогда вы получите сообщение, что такие пакеты бесплатно не публикуются.

    Таким образом, нам нужно опубликовать этот пакет как публичный:

    npm publish --access=public

    А теперь вы можете зайти на npmjs и посмотреть, что получилось.

    Обновление вашего пакета

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

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

    Цифры в номере версии говорят следующее:

    • 1: «мажорное» изменение, в нем могут быть несовместимые изменения в функциях
    • 2: «минорное» изменение, чаще всего имеет обратную совместимость
    • 3: изменение-патч, чаще всего исправление багов.

    Почитать больше на эту тему можно на сайте semver.

    Обновив версию, вы можете ее опубликовать, как делали ранее:

    npm publish # Или, если имя вашего пакета содержит префикс в виде вашего имени: npm publish --access=public

    Заключение

    Вот и все. Теперь у вас есть ваш собственный пакет в реестре NPM!

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *