By default npm will publish to the public registry. This can be overridden by specifying a different default registry or using a npm help scope in the name, combined with a scope-configured registry (see \fB\fBpackage.json\fR\fR\fI\(la/configuring-npm/package-json\(ra\fR).
Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with npm help unpublish.
As of \fBnpm@5\fR, both a sha1sum and an integrity field with a sha512sum of the tarball will be submitted to the registry during publication. Subsequent installs will use the strongest supported algorithm to verify downloads.
Certain files that are relevant to package installation and distribution are always included. For example, \fBpackage.json\fR, \fBREADME.md\fR, \fBLICENSE\fR, and so on.
.IP\(bu4
If there is a "files" list in \fB\fBpackage.json\fR\fR\fI\(la/configuring-npm/package-json\(ra\fR, then only the files specified will be included. (If directories are specified, then they will be walked recursively and their contents included, subject to the same ignore rules.)
.IP\(bu4
If there is a \fB.gitignore\fR or \fB.npmignore\fR file, then ignored files in that and all child directories will be excluded from the package. If \fIboth\fR files exist, then the \fB.gitignore\fR is ignored, and only the \fB.npmignore\fR is used.
.P
\fB.npmignore\fR files follow the \fBsame pattern rules\fR\fI\(lahttps://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring\(ra\fR as \fB.gitignore\fR files
.IP\(bu4
If the file matches certain patterns, then it will \fInever\fR be included, unless explicitly added to the \fB"files"\fR list in \fBpackage.json\fR, or un-ignored with a \fB!\fR rule in a \fB.npmignore\fR or \fB.gitignore\fR file.
.IP\(bu4
Symbolic links are never included in npm packages.
Unscoped packages can not be set to \fBrestricted\fR.
.P
Note: This defaults to not changing the current access level for existing packages. Specifying a value of \fBrestricted\fR or \fBpublic\fR during publish will change the access for an existing package the same way that \fBnpm access set
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
