Table of contents
1.4 Verify the checksum of the cached package
1、npm doctor
1.1 Commands
npm doctor [ping] [registry] [versions] [environment] [permissions] [cache]1.2 Description
npm doctor Runs a set of checks to make sure your npm installation has what it needs to manage JavaScript packages. npm is primarily a standalone tool, but it does have some basic requirements that must be met:
- Node.js and git must be executable by npm.
- The main npm registry
registry.npmjs.comor other services using the registry API are available. - The directories used by npm
node_modules(both local and global) exist and are writable by the current user. - The npm cache exists and the tarball inside it is not corrupted.
If all of these don't work, npm may not be working. Many problems are often caused by things outside of the npm codebase, so npm doctor make sure your npm installation is in good shape.
Also, on top of that, there are also a ton of problem reports due to using older versions of npm. Since npm is constantly being improved, it works npm@latest better than older versions.
npm doctor Verify the following items in your environment and if there are any suggested changes it will display them. By default, npm runs all of these checks. You can limit which checks are run by specifying the checks as extra arguments.
npm ping
By default, npm registry.npmjs.org installs from the main npm registry. npm doctor Hit a special ping endpoint in the registry. This can also be npm ping checked with . If this check fails, you may be using a proxy that needs to be configured.
This check is done against any registry you have configured (you can npm config get registry view its contents by running ), /whoami and may fail if you are using a private registry that does not support the endpoints supported by the main registry.
We can test the connection to the registry through this:
npm -v
While Node.js may be packaged with a specific version of npm, it is the policy of the CLI team that we recommend that all users run when possible npm@latest. Since the CLI is maintained by a small group of contributors, there is only one source of development lines, so npm's own long-term support releases usually only receive critical security and regression fixes. The team believes that the latest tested npm version is almost always likely to be the most feature-free and bug-free version available on npm.
So in many cases, we'd better update npm to the latest version, otherwise an error will be reported when installing dependencies.
node -v
For most users, and in most cases, the best version of Node will be the latest Long Term Support (LTS) release. Those who want to access new ECMAscript features or make cutting-edge changes to Node's standard library may be running newer versions, and due to enterprise change control policies, some may need to run older versions of Node. It doesn't matter! But in general, the npm team recommends that most users run Node.js LTS.
npm config get registry
You may be installing from a private package registry for your project or company. That's great! Others may follow tutorials or StackOverflow questions for questions you may have. Sometimes, this may require changing the registry you point to. npm doctor This part of the is just to let you, and maybe someone helping you with support, know that you're not using the default registry.
which git
Although it's documented in the README, it might not be obvious that npm needs Git installed to do many of the things it does. Also, in some cases - especially on Windows - you may PATH set up Git in such a way that it is not accessible via Git, so that npm can find it. This check ensures that Git is available.
1.3 Permission check
- Your cache must be readable and writable by the user npm is running as.
- Global package binaries must be writable by the user running npm.
- Your local
node_modulespath, if you're running from the project directorynpm doctor, must be readable and writable by the user running npm.
1.4 Verify the checksum of the cached package
When publishing an npm package, the publishing process generates a checksum that npm uses at install time to verify that the package was not corrupted in transit. npm doctor Use these checksums to verify the package tarball in your local cache (you can npm config get cache view the location of that cache with ). If you have corrupt packages in your cache, you should probably run npm cache clean -f and reset the cache.
For example, the following qs package has corresponding checksum, tarball, signature and other information.
2、npm edit
2.1 Commands
npm edit <pkg>[/<subpkg>...]2.2 Description
editor Select a dependency in the current project and open the package folder (or whatever you have configured as npm configuration - see npm-config .) in the default editor .
After it has been edited, the package is rebuilt in order to pick up any changes in the compiled package.
For example, you could perform npm install qsan install of the connection into your package, and then perform npm edit qssome changes to the locally installed copy.
This is equivalent to opening an empty file, filling in the content or closing it directly will rebuild it, which feels a bit tasteless! ! !
2.3 configuration
editor
- Default: EDITOR or VISUAL environment variable, or '%SYSTEMROOT%\notepad.exe' on Windows, or 'vi' on Unix systems
- Type: string
3、npm exec
3.1 Commands
npm exec -- <pkg>[@<version>] [args...]
npm exec --package=<pkg>[@<version>] -- <cmd> [args...]
npm exec -c '<cmd> [args...]'
npm exec --package=foo -c '<cmd> [args...]'
别名: x3.2 Description
This command allows you npm run to run arbitrary commands from npm packages (locally installed or fetched remotely) in a context similar to running them via.
--call Run without positional arguments or , which allows you package.json to run commands interactively in the same shell environment as the script runs. Interactive mode is not supported in CI environments to prevent hangs when standard input is a TTY.
--package Any packages specified by the options will be provided in the executed command PATH , as well as any locally installed package executables. --package Options may be specified multiple times to execute the provided command in environments where all specified packages are available.
If any of the requested packages do not exist in the local project dependencies, a prompt will be printed, which can be suppressed by providing --yes or . --noAssumed when standard input is not a TTY or a CI environment is detected --yes. The requested package is installed into a folder in the npm cache which is added to the PATH environment variables during execution.
A package name without a specifier will match any version present in the local project. A package name with a specifier will only be considered a match if it has the exact same name and version as the local dependency.
If no -c or --call option is given, the command string is built using the positional arguments. If no --package options are given, npm will try to determine the executable name from the package specifier provided as the first positional argument according to the following heuristics:
- If the package
package.jsonhas an entry in the field , or if all entries are aliases for the same command, that command will be used.bin - This command will be used if the package has multiple
binentries, one of whichnamematches the unscoped part of the field. - If this does not result in exactly one option (either because there are no bin entries, or none of them match the package
name), thennpm execexit with an error.
To run binaries other than those specified, specify one or more --package options, which prevent npm from inferring packages from the first command argument.
npx and npm exec
When running through npx a binary, all flags and options must be set before any positional arguments. By npm exec runtime, the double-hyphen -- flag can be used to disable npm from parsing switches and options that should be sent to the executed command.
For example:
npx foo@latest bar --package=@npmcli/fooIn this case npm will resolve foo the package name and run the following command:
$ foo bar --package=@npmcli/fooSince --package an option comes after a positional argument, it is considered an argument to the executed command.
$ npm exec foo@latest bar --package=@npmcli/fooIn this case, npm resolves --package the options first, then @npmcli/foo the package. It will then execute the following commands in that context:
$ foo@latest barIt is recommended to use double hyphens to explicitly tell npm to stop parsing command line options and switches. Therefore, the following command is equivalent to the above npx command:
$ npm exec -- foo@latest bar --package=@npmcli/foo3.3 configuration
package
- Defaults:
- Type: string (can be set multiple times)
One or more packages to install for npm exec .
call
- Defaults: ""
- Type: string
npm exec, npx an optional companion option that allows specifying custom commands to run with installed packages.
npm exec --package yo --package generator-node --call "yo node"workspace
- Defaults:
- Type: string (can be set multiple times)
Enables running commands in the context of the current project's configured workspaces, while filtering by only running workspaces defined by this configuration option.
workspace Valid values for configuration are:
- workspace name
- Path to the workspace directory
- Path to the parent workspace directory (will cause all workspaces in that folder to be selected)
When npm init set for a command, it can be set to a folder of a workspace that does not yet exist to create a folder and set it as a brand new workspace in the project.
This value is not exported to the child process' environment.
workspaces
- Default: null
- Type: null or boolean
Set to true to run the command in the context of all configured workspaces.
Explicitly setting this to false will cause install commands like this to ignore workspaces entirely. When not explicitly set:
- Commands run on
node_modulesthe tree (install, update, etc.) link workspaces tonode_modulesfolders. - Commands that perform other operations (test, execute, publish, etc.) will run on the root project unlessworkspaceone or more workspaces are specified in the configuration.
This value is not exported to the child process' environment.
include-workspace-root
- Default: false
- Type: Boolean
Include the workspace root when enabling workspaces for the command.
When false, workspace specifying a single workspace via config, or workspaces all workspaces via the flag, will cause npm to only run on the specified workspace, rather than the root project.
3.4 Examples
npm x --package=jiang-isarray
npx --package=jiang-isarrayRun an arbitrary shell script in the context of the current project:
