Table of contents
1、npm bugs
npm bugspackage.json Running this command will open the current package's corresponding page in the npm registry. If no package name is provided, it will search and use name properties in the current folder .
For example, in the following path, execute the npm bugs command, as shown below:
You can also directly specify the package name, and open the path corresponding to the package in the npm registry. For example:
npm bugs jiang-isarry
1.1 configuration
browser
- Default: OS X:
"open", Windows:"start", Others:"xdg-open" - Type: null, boolean, or string
Set to false suppress the browser behavior and instead print the url to the terminal.
Set to true use the default system URL opener.
registry
- Default: " https://registry.npmjs.org/"
- Type: URL
The base URL for the npm registry.
2、npm cache
2.1 Overview
Commonly used commands for npm cache are as follows:
npm cache add <package-spec>
npm cache clean [<key>]
npm cache ls [<name>@<version>]
npm cache verifyUsed to add, list, verify or clean npm cache folders.
- add: Add the specified package to the local cache. This command is mostly used internally by npm, but it can provide a way to explicitly add data to the locally installed cache
- clean: Deletes all data from this cache folder. Note that this is usually unnecessary since npm's cache is self-healing and resistant to data corruption issues.
- ls: list cache files
- verify: Verify the contents of this cache folder, garbage collect any unneeded data, and verify the integrity of the cache index and all cached data.
2.2 Details
npm stores cache data in cache an opaque directory named _cacache. This directory is a cacache -based content-addressable cache that stores all http request data as well as other package-related data. This directory is primarily pacote accessed by the library responsible for fetching all packages starting from npm@5.
All data passing through the cache is fully validated on insertion and extraction. A cache corruption will trigger an error, or pacote signal to the server, that the data must be re-fetched, which will be done automatically. For this reason, the cache should never need to be cleared, other than to reclaim disk space, which is why it clean needs to be run now --force .
There is currently no method exposed through npm to inspect or directly manage the contents of this cache. In order to access it, it must be used directly cacache.
npm doesn't delete data on its own: the cache grows as new packages are installed.
2.3 Notes on cache design
The npm cache is strictly a cache: it should not be relied upon as a persistent, reliable data store for package data. npm makes no guarantees that previously cached data will be available later, and will automatically delete corrupted content. The main guarantee the cache makes is that if it does return data, that data will be exactly as it was inserted.
To run offline validation on existing cached content, use npm cache verify.
2.4 configuration
cache
- Default: Windows:
%LocalAppData%\npm-cache, Posix:~/.npm - Type: path
The location of npm's cache directory.
3、 asl c
3.1 Description
This command is similar to npm install , except that it is intended for use in automated environments, such as test platforms, continuous integration, and deployment - or any situation where you want to ensure a clean install of dependencies.
The main difference between using npm install and npm ci is:
- Item must have an existing
package-lock.jsonornpm-shrinkwrap.json. - If the dependencies in the package-lock
package.jsondo not match the dependencies in the package-lock,npm ciexit with an error instead of updating the package-lock. npm ciOnly the entire project can be installed at once: individual dependencies cannot be added with this command.- If
node_modulesit already exists, it willnpm cibe automatically removed before starting the installation. - It never writes
package.jsonor any package locks: the installation is basically frozen.
Note: If you run buildfile with flags that may affect the shape of the dependency tree (such as or --legacy-peer-deps ) --install-links, you must provide the same flags, or you may encounter errors. An easy way is to run eg and commit the files to your repo.npm installpackage-lock.jsonnpm cinpm config set legacy-peer-deps=true --location=project.npmrc
3.2 configuration
install-strategy
- Default: "hoisted"
- Type: "hoisted", "nested", "shallow", or "linked"
Sets the policy for installing packages in node_modules. hoisted (default): Install non-replicated at the top level, and replicate as needed in the directory structure. nested : (formerly --legacy-bundling) install in-place, without elevating. shallow (formerly --global-style) only installs immediate deps at the top level. linked : (experimental) installed in node_modules/.store, linked in place, not elevated.
legacy-bundling
- Default: false
- Type: Boolean
- DEPRECATED: This option has been enabled in favor of
--install-strategy=nested
Do not node_modules elevate package installations in , but install packages in the same way that they depend on. This can lead to very deep directory structures and duplicate package installations because there is no data deduplication. settings --install-strategy=nested.
global-style
- Default: false
- Type: Boolean
- DEPRECATED: This option has been deprecated in favor of
--install-strategy=shallow
Only node_modules install direct dependencies in the top level, but promote deeper dependencies. settings --install-strategy=shallow.
omit
- Default: 'dev' if
NODE_ENVthe environment variable is set to 'production', empty otherwise. - Type: "dev", "optional", "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies are still resolved and added to package-lock.json or npm-shrinkwrap.json files. They're just not physically installed on the disk.
If a package type appears in both the --include and --omit list, then it will be included.
The environment variable will be set to for all lifecycle scripts 'dev'if the generated omission list contains .NODE_ENV'production'
strict-peer-deps
- Default: false
- Type: Boolean
If set to true, and --legacy-peer-deps not set, any conflicting peerDependencies ones will be treated as install failures, even if npm can reasonably guess an appropriate resolution based on non-peer dependencies.
By default, conflicts in the dependency graph peerDependencies will be resolved using the nearest non-peer dependency specification, even if doing so would cause some packages to receive peer peerDependencies dependencies beyond the scope set in their package's objects.
When such an override is performed, a warning is printed explaining the conflict and the packages involved. If set --strict-peer-deps, this warning is considered a failure.
foreground-scripts
- Default: false
- Type: Boolean
preinstallRuns all build scripts (ie , install and postinstall) scripts of an installed package in a foreground process , sharing standard input, output, and error with the main npm process.
Note that this generally makes the install run slower and noisier, but is useful for debugging.
ignore-scripts
- Default: false
- Type: Boolean
If true, npm will not run scripts specified in the package.json file.
Note that if set ignore-scripts, commands explicitly intended to run a specific script (such as npm start, npm stop, npm restart, npm test and npm run-script) will still run their intended script, but they will not run any pre- or post-scripts.
audit
- Default: true
- Type: Boolean
When "true" submits audit reports with the current npm command to the default registry and all registries configured for the scope.
bin-links
- Default: true
- Type: Boolean
Tells npm to create symlinks (or shims on Windows .cmd ) to the package's executable.
Set to false to have it not do this. This can be used to work around the fact that some filesystems don't support symbolic links, even on ostensibly Unix systems.
fund
- Default: true
- Type: Boolean
When "true" npm install is displayed at the end of each message, confirming that the number of dependencies is looking for funds.
dry-run
- Default: false
- Type: Boolean
means you don't want npm to make any changes, and it should only report what it would. This can be passed to any command that modifies the local installation, such as install, update, dedupe, uninstall and pack . publish
NOTE: This feature is not supported by other network-related commands, such as dist-tags, owner etc.
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.
This value is not exported to the child process' environment.
install-links
- Default: false
- Type: Boolean
When setting the file: protocol dependencies will be packaged and installed as regular dependencies instead of creating symlinks. This option has no effect on workspaces.