After we write an application, we need to publish to NPM. Most of us might just use NPM Publish. Here’s how to better publish packages.
1. registry
When downloading packages, many people like to set up Taobao mirror, because the NPM warehouse server is in a foreign country, the download speed is really desperate. In package.json, you can set the address of the package you want to publish:
"publishConfig": {
"registry": "http://registry.npm.xxx.com/"
}
Copy the code
Aliases can also be set
alias ynpm="npm --registry=http://registry.npm.xxx.com"
// Release time
ynpm publish
Copy the code
2. Permissions are related
To publish the package, you need to verify your account permissions. The first time you run NPM adduser, then you only need NPM login. Sometimes we encounter that your user name and password is wrong, but it is actually not correct. It may be because your Registry is set as the URL of Taobao mirror. NPM configuration can be checked by going to ~/. Use NPM owner add
[<@scope>/]< PKG > to add a user, but it is better to tighten the publishing permission, others carry MR, package owner code review, and then send the package.
3. What documents will be released?
Release a package, considering other people’s download speed, package size must be as small as possible, so the source file had better not include, then how to control which files only send?
Json. The value of the Files field is an array. You can write specific file names, directories, and glob mode.
The second option is to use the.npmignore configuration file, which is similar to the.gitignore file, but if there is no.npmignore, it will use.gitignore instead of its functionality. .npmignore does not overwrite the files field at the root of the package, but does in subdirectories.
Some files cannot be excluded or included beyond configuration:
- package.json
- README
- CHANGES / CHANGELOG / HISTORY
- LICENSE / LICENCE
- NOTICE
- Files in the main field
The above files cannot be ignored.
- .git
- CVS
- .svn
- .DS_Store
- . _ *
- , etc.
The above files cannot be published to NPM.
4. Version management
NPM packages need to follow the semantic version, a version number contains three parts: major.minor.patch,
- MAJOR means the MAJOR version number when you make incompatible API changes;
- MINOR is the MINOR version number when you make a backward-compatible functional addition;
- PATCH stands for revision number, when you make a downward compatible problem fix;
We can use the NPM version command to automatically change the version number, for example:
/ / 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
Copy the code
Generally there are pre-builds, beta builds, and so on, and they call it that
- 3.1.0 – beta. 0
- 3.1.0 – alpha. 0
If we were to release an earlier version, the NPM version prepatch command would not give us a canonical version number. We would have to use NPM version 1.0.0-alpha.1 to specify a version number, but after NPM 6.4.0, We can use the –preid argument:
npm version prerelease --preid=alpha
Copy the code
5. Changelog
After a package has been released many times, the user needs to know if he needs to upgrade, and needs to see the documentation to see if there are any incompatibable changes, so a Changelog is needed to keep track of what has been changed with each release. If manual maintenance, it will be forgotten, so you need to use tools to automatically generate, we can use the standard-version package to generate, this package is used to automatically update the version and generate CHANGELOG.
Standard-version --prerelease alpha stocking bumping version in package.json from 3.0.2-0 to 3.0.2-alpha.0 stocking bumping Changelog. md stocking outputting changes to Changelog. md stocking package. Json and Changelog. md stocking tagging release V3.0.2-alpha.0 ℹ Run 'git push --follow tags origin master publish --tag alpha to publish Bug Fixes * add functionality 1 75 e2808 # # # [3.0.2 - alpha. 0] (/ / / the compare/v3.0.2-0... V3.0.2 - alpha. 0) (2019-06-18)Copy the code
With this tool we do not need to use NPM Version Prepatch. Standard-version will automatically log new features and bug fixes based on your Git commit information. Git commit automatically means that you need to follow a format like:
- 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
We can use CommitLint with HusKY to verify that your commit information is compliant
{
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"}}}Copy the code
You can also generate a COMMIT interactively, such as the commitizen package.
6. Tag
Git tag: git tag: git tag
The tag of the git
Git tagging should be familiar to us, especially those who develop SDK or APP software. Git tag -a
-m < comment text > Push the tag to remote with git push — tags Origin master.
The tag of NPM
We can view the tag of a package through NPM dist-tag ls [< PKG >]. Generally we have at least three types of tags
- This is the latest version of NPM install
- Beta: Indicates the test version, which is generally used for internal testing. You need to specify the version number of install, for example, 3.1.0-bet.0
- Next: prior version, NPM install foo@next, for example 3.0.2-alpha.0
If we need to release a beta, we need to do it at release time
npm publish --tag beta
Copy the code
If you publish directly, you will be tagged with latest by default, even if your version number is -beta.n, and it will be downloaded when others install it. At this time, we just need to change the tag:
// It was sent by mistake
latest: 1.01.-beta. 0
// Set 1.0.1-beta.0 to beta
npm dist-tag add my-package@1.01.-beta. 0 beta
npm dist-tag add my-package@1.0. 0 latest
Copy the code
Then everything will be all right.
Wulv. site/2019-06-17/…