账户
npm login
登录npm whoami
查看当前登录信息
源
可以通过 npmrc
这个工具来管理源
npm i npmrc -g
// 创建
npmrc -c name
npm config set registry xxx
// 切换
npmrc name
About scopes
When you sign up for an npm user account or create an organization, you are granted a scope that matches your user or organization name. You can use this scope as a namespace for related packages.
Scopes and package visibility
- Unscoped packages are always public.
- Private packages are always scoped.
- Scoped packages are private by default; you must pass a command-line flag when publishing to make them - public.
About public packages
As an npm user or organization member, you can create and publish public packages that anyone can download and use in their own projects.
- Unscoped public packages exist in the global public registry namespace and can be referenced in a package.json file with the package name alone:
package-name.
- Scoped public packages belong to a user or organization and must be preceded by the user or organization name when included as a dependency in a package.json file:
@username/package-name
@org-name/package-name
npm init --scope=@scope-name
About private packages
To use private packages, you must have a paid user or organization account. Private packages always have a scope, and scoped packages are private by default.
- User-scoped private packages can only be accessed by you and collaborators to whom you have granted read or read/write access
- Organization-scoped private packages can only be accessed by teams that have been granted read or read/write access.
Publish package
- For private packages and unscoped packages, use
npm publish
. - For scoped public packages, use
npm publish --access public
Creating and publishing unscoped public packages
You can only publish unscoped packages to the npm public registry. You cannot publish unscoped packages to an npm Enterprise registry
npm run publish
Creating and publishing scoped public packages
To share your code publicly in a user or organization namespace, you can publish public user-scoped or organization-scoped packages to the npm registry.
- create:
npm init --scope=@组织scope|@个人scope
- publish:
npm run publish --access public
Creating and publishing private packages
To share your code with a limited set of users or teams, you can publish private user-scoped or organization-scoped packages to the npm registry.
By default, scoped packages are published with private visibility. npm run publish
About semantic versioning
Adding dist-tags to packages
By default, running npm publish
will tag your package with the latest
dist-tag. To use another dist-tag, use the --tag
flag when publishing.
npm publish --tag <tag>
Adding a dist-tag to a specific version of your package
npm dist-tag add <package-name>@<version> [<tag>]
then when install,you can directly use npm i <package-name>@<tag>
instead of npm i <package-name>@<version>
Changing package visibility
You can change the visibility of a scoped package. You cannot change the visibility of an unscoped package. Only scoped packages with a paid subscription may be private.
- Making a public package private:
npm access restricted <package-name>
- Making a private package public:
npm access public <package-name>
Updating your published package version number
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=prerelease-id]]
npm verseion | Description |
---|---|
major | 如果没有预发布号,major + 1 ,minor、patch 置为 0。 如果有预发布号,若 minor 和 patch 都为 0,major 不变,而将预发布号删掉。若 minor 和 patch 有一个不为 0,major + 1 ,minor、patch 置为 0,清空预发布号。 |
minor | 如果没有预发布号,minor + 1 ,patch 置为 0。 如果有预发布号,若 patch 为 0,minor 不变,而将预发布号删掉。若 patch 有不为 0,minor + 1 ,patch 置为 0,清空预发布号。 |
patch | 如果没有预发布号,patch + 1 。 如果有预发布号,patch 不变,清空预发布号。 |
premajor | major + 1 ,minor、patch 置为 0,增加预发布号为 0 |
preminor | minor + 1 ,patch 置为 0,增加预发布号为 0 |
prepatch | patch + 1 ,增加预发布号为0 |
prerelease | 如果没有预发布号,patch + 1 ,增加预发布号为0。如果有预发布号,则升级预发布号 |
Deprecating and undeprecating packages or package versions
- Deprecating an entire package
Deprecating an entire package will remove it from search results on the npm website and a deprecation message will also be displayed on the package page.
npm deprecate <package-name> "<message>"
- Deprecating a single version of a package
npm deprecate <package-name>@<version> "<message>"
- Undeprecating a package or version: To undeprecate a package, replace “” with “” (an empty string) in one of the above commands.
Unpublishing packages from the registry
As a package owner or collaborator, if your package has no dependents, you can permanently remove it from the npm registry
- Unpublish all version:
npm unpublish <package-name> -f
- Unpublishing a single version of a package:
npm unpublish <package-name>@<version>
Install packages
- unscoped package: Unscoped packages are always public, which means they can be searched for, downloaded, and installed by anyone
- scoped public package: Scoped public packages can be downloaded and installed by anyone
- private package: Private packages can only be downloaded and installed by those who have been granted read access to the package
Resolving EACCES permissions errors when installing packages globally
update package version
npm update
update locallynpm outdated
list outdated packagenpm outdated -g --depth=0
npm update -g <package_name>
npm update -g
Floder
Npmrc
config
npmrc
Package.json
dependencies
you can provide a path to a local directory that contains a package. This feature is helpful for local offline development and creating tests that require npm installing where you don’t want to hit an external server,
peerDependencies
In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a require of this host. This is usually referred to as a plugin.
{
"name": "tea-latte",
"version": "1.3.5",
"peerDependencies": {
"tea": "2.x"
}
}
This ensures your package tea-latte can be installed along with the second major version of the host package tea only. npm install tea-latte could possibly yield the following dependency graph:
├── tea-latte@1.3.5
└── tea@2.2.0
In npm versions 3 through 6, peerDependencies were not automatically installed, and would raise a warning if an invalid version of the peer dependency was found in the tree. As of npm v7, peerDependencies are installed by default.
Trying to install another plugin with a conflicting requirement may cause an error if the tree cannot be resolved correctly. For this reason, make sure your plugin requirement is as broad as possible, and not to lock it down to specific patch versions.
When a user installs your package, npm will emit warnings if packages specified in peerDependencies are not already installed.
private
If you set "private": true
in your package.json, then npm will refuse to publish it.