A command that automates the management of \fBpackage.json\fR files. \fBnpm pkg\fR provide 3 different sub commands that allow you to modify or retrieve values for given object keys in your \fBpackage.json\fR.
The syntax to retrieve and set fields is a dot separated representation of the nested object properties to be found within your \fBpackage.json\fR, it's the same notation used in npm help view to retrieve information from the registry manifest, below you can find more examples on how to use it.
For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list. For example, to get all the contributor emails for a package, you would run:
You may also use numeric indices in square braces to specifically select an item in an array field. To just get the email address of the first contributor in the list, you can run:
For complex fields you can also name a property in square brackets to specifically select a child field. This is especially helpful with the exports object:
Sets a \fBvalue\fR in your \fBpackage.json\fR based on the \fBfield\fR value. When saving to your \fBpackage.json\fR file the same set of rules used during \fBnpm install\fR and other cli commands that touches the \fBpackage.json\fR file are used, making sure to respect the existing indentation and possibly applying some validation prior to saving values to the file.
.P
The same syntax used to retrieve values from your package can also be used to define new properties or overriding existing ones, below are some examples of how the dot separated syntax can be used to edit your \fBpackage.json\fR file.
.P
Defining a new bin named \fBmynewcommand\fR in your \fBpackage.json\fR that points to a file \fBcli.js\fR:
It's also possible to parse values as json prior to saving them to your \fBpackage.json\fR file, for example in order to set a \fB"private": true\fR property:
Auto corrects common errors in your \fBpackage.json\fR. npm already does this during \fBpublish\fR, which leads to subtle (mostly harmless) differences between the contents of your \fBpackage.json\fR file and the manifest that npm uses during installation.
You can set/get/delete items across your configured workspaces by using the \fB\fBworkspace\fR\fR\fI\(la/using-npm/config#workspace\(ra\fR or \fB\fBworkspaces\fR\fR\fI\(la/using-npm/config#workspaces\(ra\fR config options.
When using \fBnpm pkg get\fR to retrieve info from your configured workspaces, the returned result will be in a json format in which top level keys are the names of each workspace, the values of these keys will be the result values returned from each of the configured workspaces, e.g:
Allow clobbering non-npm files in global installs.
.IP\(bu4
Allow the \fBnpm version\fR command to work on an unclean git repository.
.IP\(bu4
Allow deleting the cache folder with \fBnpm cache clean\fR.
.IP\(bu4
Allow installing packages that have an \fBengines\fR declaration requiring a different version of npm.
.IP\(bu4
Allow installing packages that have an \fBengines\fR declaration requiring a different version of \fBnode\fR, even if \fB--engine-strict\fR is enabled.
.IP\(bu4
Allow \fBnpm audit fix\fR to install modules outside your stated dependency range (including SemVer-major changes).
.IP\(bu4
Allow unpublishing all versions of a published package.
.IP\(bu4
Allow conflicting peerDependencies to be installed in the root project.
.IP\(bu4
Implicitly set \fB--yes\fR during \fBnpm init\fR.
.IP\(bu4
Allow clobbering existing values in \fBnpm pkg\fR
.IP\(bu4
Allow unpublishing of entire packages (not just a single version).
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.