NPM common commands (1)

Table of contents

1、npm

1.1 Introduction

1.2 Dependencies

1.3 Installation method

2、npm access

2.1 Command description

2.2 Details

3、npm adduser

3.1 Description

4、npm audit

4.1 Introduction

4.2 Audit Signature

4.3 Operation example

4.4 configuration

audit-level

dry-run

force

json

package-lock-only

omit

foreground-scripts

ignore-scripts

workspace

workspaces

include-workspace-root


1、npm

On the command line, enter the npm command to display that npm can correspond to the command, as shown in the following figure:

npm

1.1 Introduction

npm is the package manager for the Node JavaScript platform. It puts modules in place so node can find them, and intelligently manages dependency conflicts.

It is configurable to support various use cases. Most commonly, you use it to publish, discover, install, and develop node programs.

Run npm help for a list of available commands.

npm is pre-configured to use npm's public registry (the default). Use of the npm public registry is governed by the terms of use available at the following website .

You can configure npm to use any compatible registry you like, or even run your own. Use of another's registry is governed by their terms of use.

1.2 Dependencies

If a package lists a dependency using a git URL, npm will use the git command to install that dependency, or generate an error if it is not installed.

If one of the packages npm is trying to install is a native node module and needs to compile C++ code, npm will use node-gyp to do that. For Unix systems, node-gyp requires Python, make and a build chain like GCC. On Windows, Python and Microsoft Visual Studio C++ are required.

1.3 Installation method

There are two ways to install npm:

  • Local installation: npm will install the package into the current project directory, which defaults to the current working directory. Packages are installed to ./node_modules
  • glob mode: npm installs the package into the install prefix $npm_config_prefix/lib/node_modules

Local mode is the default mode. Use on any command -gor --global run in global mode.

2、npm access

npm access can set the access level of published packages.

Commonly used commands are as follows:

npm access public [<package>]
npm access restricted [<package>]
npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]
npm access 2fa-required [<package>]
npm access 2fa-not-required [<package>]
npm access ls-packages [<user>|<scope>|<scope:team>]
npm access ls-collaborators [<package> [<user>]]
npm access edit [<package>]

2.1 Command description

For all subcommands, if no package name is passed to the subcommand, npm access will act on the package in the current working directory.

  • public/restricted (deprecated): Set package as publicly accessible or restricted.
  • grant/revoke (deprecated): Add or remove the ability for users and teams to have read-only or read-write access to packages.
  • 2fa-required / 2fa-not-required (deprecated): Whether the configuration package requires anyone publishing it to enable two-factor authentication on their account
  • ls-packages (deprecated): Show all packages a user or team has access to along the access level, except for read-only public packages (it doesn't print the entire registry listing)
  • ls-collaborators (deprecated): Show all access permissions for a package. will only show permissions for packages for which you have at least read access. If <user> is passed in, the list will only be filtered to the teams the user happens to belong to.
  • edit (not implemented)

2.2 Details

npm access always operates directly on the current registry, additional registry configuration can be done from the command line using --registry= <registry url>.

Unscoped packages are always public.

Scoped packages are restricted by default, but you can publish them as public with npm publish --access=public, or set their access to public with npm access public after the initial publish.

Permission to set package access permissions is required:

1. You are the owner of an unscoped or scoped package

2. You are part of a team that owns the scope.

3. You have been granted read and write access to the package, either as a team member or directly as the owner.

If you have two-factor authentication enabled, you will be prompted for a second factor proof, or specified on the command line using the --otp=... option.

If your account is not paid, then trying to publish a package in scope will fail with an HTTP 402 status code (logically sufficient), unless you use --access=public.

Management of teams and team members is done through the npm tea command.

3、npm adduser

3.1 Description

Creates a new user in the specified registry and saves the credentials to the .npmrc file. If no registry is specified, the default registry will be used.

When auth-type is legacy , username, password and email will be read from the prompt.

auth-type

  • Default:“web”
  • Type: "legacy" or "web"

What authentication strategy to use when logging in. Note that this value will always be set to legacy if an otp configuration is given.

4、npm audit

Use the command as follows:

npm audit [fix|signatures]

4.1 Introduction

The audit command submits descriptions of the dependencies configured in the project to the default registry and requests reports of known vulnerabilities. If any vulnerabilities are found, the impact and appropriate remedial actions will be calculated. If the fix argument is provided, the fix will be applied to the package tree.

If no vulnerabilities are found, the command will exit with an exit code of 0.

Note that some vulnerabilities cannot be fixed automatically and require manual intervention or review. Also note that since npm audit fix runs a full blown npm install in the background, any configuration that applies to the installer will also apply to npm install -- so something like npm audit fix --package-lock-only will work as expected.

By default, the audit command will exit with a non-zero code if any vulnerabilities are found. In a CI environment, it may be useful to include the --audit-level parameter to specify the minimum vulnerability level that will cause the command to fail. This option does not filter the report output, it just changes the command's failure threshold.

If package security would look like this:

If there is a corresponding unsafe package, the severity level of the following package is high , as shown below:

4.2 Audit Signature

To ensure the integrity of packages downloaded from the public npm registry, or any registry that supports signing, the npm CLI can be used to verify the registry signature of downloaded packages.

auditThe registry signature can be verified using the following command:

npm audit signatures

The npm CLI supports registry signing and signing keys provided by any registry if the following conventions are followed:

1. The provision of each released version of the package signed in the dist object

Example: lodash v4.17.21

lodash - npm

https://registry.npmjs.org/  + "package name" + corresponding version number, you can check the corresponding signature.

sig 是使用以下模板生成的: ${package.name}@${package.version}:${package.dist.integrity} 和 keyid 必须匹配以下公共签名密钥之一。

{
    "keys":[
        {
            "expires":null,
            "keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA",
            "keytype":"ecdsa-sha2-nistp256",
            "scheme":"ecdsa-sha2-nistp256",    
"key":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1Olb3zMAFFxXKHiIkQO5cJ3Yhl5i6UPp+IhuteBJbuHcA5UogKo0EWtlWwW6KSaKoTNEYL7JlCQiVnkhBktUgg=="
        }
    ]
}
  • expires: null or a simplified extended  ISO 8601 formatYYYY-MM-DDTHH:mm:ss.sssZ
  • keydid: the sha256 fingerprint of the public key
  • keytype: The npm CLI currently only supports ecdsa-sha2-nistp256
  • scheme: The npm CLI currently only supports ecdsa-sha2-nistp256
  • key: base64 encoded public key

4.3 Operation example

Scan your project for vulnerabilities and automatically install any compatibility updates for vulnerable dependencies:

npm audit fix

node_modules To run  without modification  audit fix, but still update pkglock:

npm audit fix --package-lock-only

Skip update  devDependencies:

npm audit fix --only=prod

Make  audit fix the top-level dependency install SemVer major updates, not just SemVer-compatible updates:

npm audit fix --force

Do a dry run to see  audit fix what it will do, and output the installation information in JSON format:

npm audit fix --dry-run --json

Get a detailed audit report in JSON format:

npm audit --json

The audit will only fail if the results contain a medium or higher level of vulnerability:

npm audit --audit-level=moderate

4.4 configuration

audit-level

  • Default: null
  • 类型: 空、"info"、"low"、"moderate"、"high"、"critical" 或 "none"

npm audit Minimum vulnerability level to exit with a non-zero exit code.

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.

force

  • Default: false
  • Type: Boolean

Various protections against unfortunate side effects, common bugs, unnecessary performance degradation, and malicious input are removed.

  • Allow breaking non-npm files in global installs.
  • Allow  npm version commands to work on unclean git repositories.
  • Allows use  npm cache clean to delete the cache folder.
  • Allows installing  engines packages with npm that declare that they require a different version.
  • Allow installation of packages with  engines declarations requiring different versions  node , even if enabled  --engine-strict.
  • Allow  npm audit fix installation of modules beyond the scope of your declared dependencies (including SemVer major changes).
  • Allows unpublishing of all versions of a published package.
  • Allow conflicting peerDependencies to be installed in the root project.
  • npm init Implicitly set  when  --yes.
  • Allow  npm pkg existing values ​​in destruction
  • Allows to unpublish the entire package (not just a single version).

If you don't have a clear idea of ​​what you want to do, I strongly recommend that you don't use this option!

json

  • Default: false
  • Type: Boolean

Whether to output JSON data instead of normal output.

  • In  npm pkg set it, it can use JSON.parse() to parse collection values ​​before saving them to your  package.json.

Not all npm commands support it.

package-lock-only

  • Default: false
  • Type: Boolean

If set to true, the current operation will only use  package-lock.json, ignore  node_modules.

For  update, this means only updating  package-lock.json, rather than checking  node_modules and downloading dependencies.

For  list, this means that the output will be based on  package-lock.json the description's tree, not  node_modules the content of the .

omit

  • Default: 'dev' if  NODE_ENV the 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'

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.

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_modules the tree (install, update, etc.) link workspaces to  node_modules folders. - Commands that perform other operations (test, execute, publish, etc.) will run on the root project unless  workspace one 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 run only on the specified workspace, rather than the root project.

This value is not exported to the child process' environment.

  • 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.

Guess you like

Origin blog.csdn.net/u014388408/article/details/132623958