После того, как мы написали приложение, которое нужно опубликовать на npm, большинство людей, вероятно, просто используютnpm publishДело сделано, здесь я расскажу о том, как лучше опубликовать пакет.
1. registry
При загрузке пакетов многие любят устанавливатьtaobaoзеркало, потому чтоnpmСервер склада находится за границей, и скорость загрузки действительно высокая. То же самое верно и при выпуске.Как правило, приложения с открытым исходным кодом в основном выпускаются дляnpmjs, если внутренний пакет компании отправляется в частныйNpmсклад, мы можемpackage.jsonУстановите адрес, на который вы хотите опубликовать:
"publishConfig": {
"registry": "http://registry.npm.xxx.com/"
}
Вы также можете установить псевдоним
alias ynpm="npm --registry=http://registry.npm.xxx.com"
// 发布的时候
ynpm publish
2. Разрешение, связанное с
Пакет выпуска должен проверить разрешения вашей учетной записи, первое выполнениеnpm adduser, то нужно толькоnpm login. Иногда мы сталкиваемся с тем, что ваше имя пользователя и пароль неверны, но это неправда, это может быть из-за вашегоregistryУстановите URL-адрес зеркала Taobao, конфигурация npm может перейти к~/.npmrcвид, черезnpm config delete registryудалять. Если вам нужен кто-то, кто поможет вам отправить посылку вместе, вы можете использоватьnpm owner add <user> [<@scope>/]<pkg>Иди добавляй пользователя, но лучше ужесточить права на публикацию, другие люди упоминают MR, пакетownerпровестиcode review, а затем отправить пакет.
3. Какие документы публикуются?
При публикации пакета, учитывая скорость загрузки других, размер пакета должен быть как можно меньше, поэтому лучше не включать исходные файлы.Как контролировать, какие файлы только отправляются?
Первый способ вpackage.jsonвнутриfilesполе для контроля,filesЗначением поля является массив, можно написать конкретное имя файла, также можно написать каталог, так же поддерживаетglobмодель.
Второй заключается в использовании.npmignoreконфигурационный файл, похожий на.gitignoreфайл, на самом деле если нет.npmignore,Будет использовано.gitignoreзаменить его функцию. В корневом каталоге пакета.npmignoreне перезапишетfilesполя, но будут перезаписаны в подкаталогах.
Некоторые файлы не могут быть исключены или включены в конфигурацию:
- package.json
- README
- CHANGES / CHANGELOG / HISTORY
- LICENSE / LICENCE
- NOTICE
- файл в основном поле
Вышеуказанные файлы нельзя игнорировать.
- .git
- CVS
- .svn
- .DS_Store
- ._*
- так далее
Вышеупомянутый файл не может быть опубликован наnpm.
4. Управление версиями
Распространение пакета npm должно соответствовать семантической версии, а номер версии состоит из трех частей:MAJOR.MINOR.PATCH,
- MAJOR представляет основной номер версии, когда вы вносите несовместимые изменения API;
- MINOR представляет дополнительный номер версии, когда вы добавляете функции, совместимые с предыдущими версиями;
- PATCH указывает номер версии, когда вы делаете исправление для обратной совместимости;
мы можем использоватьnpm versionкоманда для автоматического изменения номера версии, например:
// version = v1.0.0
npm version patch
// v1.0.1
npm version prepatch
// v1.0.2-0
npm version minor
// v1.1.0
npm version major
// v2.0.0
В общем, есть еще продвинутые версии, бета-версии и т. д., они так и называются
- 3.1.0-beta.0
- 3.1.0-alpha.0
Если мы выпустим предварительную версию,npm version prepatchКажется, что номер версии, полученный командой, недостаточно стандартизирован, мы можем использовать толькоnpm version 1.0.0-alpha.1Укажите номер версии, но, к счастью, вnpm 6.4.0После этого мы можем использовать--preidпараметр:
npm version prerelease --preid=alpha
5. Changelog
После того, как пакет был выпущен много раз, пользователь должен знать, нужно ли ему обновление, и ему нужно проверить документацию, чтобы увидеть, что такое несовместимость, поэтому ему нуженChangelogчтобы записать, что изменилось с каждым выпуском. Если ручное обслуживание точно будет забыто, поэтому вам нужно использовать инструменты для автоматической генерации, мы можем использоватьstandard-versionЭтот пакет генерируется.Функция этого пакета состоит в том, чтобы автоматически обновлять версию и генерироватьCHANGELOG.
standard-version --prerelease alpha
✔ bumping version in package.json from 3.0.2-0 to 3.0.2-alpha.0
✔ created CHANGELOG.md
✔ outputting changes to CHANGELOG.md
✔ committing package.json and CHANGELOG.md
✔ tagging release v3.0.2-alpha.0
ℹ Run `git push --follow-tags origin master && npm publish --tag alpha` to publish
// 再看下生成的Changelog
### Bug Fixes
* 添加功能1 75e2808
### [3.0.2-alpha.0](///compare/v3.0.2-0...v3.0.2-alpha.0) (2019-06-18)
С этим инструментом нам всем не нужно использоватьnpm version prepatch.standard-versionбудет основываться на вашемgit commitинформацию, автоматически генерировать журналы, такие как добавление новых функций и исправление ошибок. В то же время, что он генерируется автоматически, это означает, что выgit commitОн должен соответствовать определенному формату, например:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-co lons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
мы можем использоватьcommitlintсоответствоватьhuskyЧтобы проверить, соответствует ли ваша информация о коммите стандарту
{
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
}
Коммиты также можно генерировать в интерактивном режиме,commitizenЭтот пакет подойдет.
6. Tag
Прежде чем объяснять тег npm, нам нужно поговорить о теге git:
git-тег
Мы должны быть знакомы с тегами в git, особенно тем, кто разрабатывает программное обеспечение sdk или APP. мы используемnpm version prepatchбудет выполняться по умолчанию один разgit tag versionМы также можем играть на этикетку вручную.git tag -a <tag名> -m <注释文字>,пройти черезgit push — tags origin masterПрижмите этикетку к пульту.
npm-теги
мы можем пройтиnpm dist-tag ls [<pkg>]Чтобы просмотреть тег пакета, в общем случае у нас будет как минимум три типа тегов.
- последняя: последняя версия, это то, что устанавливает npm
- Бета-версия: тестовая версия, обычное использование бета-версии, требует установки указанного номера версии, например 3.1.0-beta.0.
- следующая: предыдущая версия, npm install foo@next install, например 3.0.2-alpha.0
Если нам нужно выпустить тестовую версию, нам нужно выполнить
npm publish --tag beta
Если вы выполняете напрямуюnpm publish, то даже если номер вашей версии-beta.n, будет отмечен по умолчаниюlatestlabel, он также будет загружен, когда другие установят его. На данный момент нам просто нужно изменить тег:
// 不小心发错了
latest: 1.0.1-beta.0
// 将1.0.1-beta.0设置为beta
npm dist-tag add my-package@1.0.1-beta.0 beta
npm dist-tag add my-package@1.0.0 latest
Это хорошо.
Эта статья была впервые опубликована в моем личном блоге:Не беспокойтесь.сайт/2019-06-17/…