npm がインストールしようとしているパッケージの 1 つがネイティブノードモジュールであり、C++ コードをコンパイルする必要がある場合、npm はそれを行うために node-gyp を使用します。Unix システムの場合、node-gyp には Python、make、GCC などのビルドチェーンが必要です。Windows では、Python および Microsoft Visual Studio C++ が必要です。

1.3 インストール方法

npm をインストールするには 2 つの方法があります。

ローカルインストール: npm はパッケージを現在のプロジェクトディレクトリにインストールします。デフォルトは現在の作業ディレクトリです。パッケージは次の場所にインストールされます ./node_modules
glob モード: npm はパッケージをインストールプレフィックスにインストールします $npm_config_prefix/lib/node_modules

ローカルモードがデフォルトのモードです。任意のコマンドで使用する-gか、--global グローバルモードで実行します。

2、npmアクセス

npm access は、公開されたパッケージのアクセスレベルを設定できます。

一般的に使用されるコマンドは次のとおりです。

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 コマンドの説明

すべてのサブコマンドで、パッケージ名がサブコマンドに渡されない場合、npm アクセスは現在の作業ディレクトリ内のパッケージに作用します。

public/restricted (非推奨): パッケージをパブリックにアクセス可能または制限付きとして設定します。
付与/取り消し (非推奨): ユーザーおよびチームがパッケージに対して読み取り専用または読み取り/書き込みアクセスを持つ機能を追加または削除します。
2fa-required / 2fa-not-required (非推奨): 構成パッケージを公開するユーザーに、アカウントで 2 要素認証を有効にするよう要求するかどうか
ls-packages (非推奨): 読み取り専用のパブリックパッケージを除き、ユーザーまたはチームがアクセスできるすべてのパッケージをアクセスレベルに沿って表示します (レジストリリスト全体は出力されません)。
ls-collaborators (非推奨): パッケージのすべてのアクセス許可を表示します。少なくとも読み取りアクセス権があるパッケージの権限のみが表示されます。<user> が渡された場合、リストはユーザーがたまたま所属しているチームのみにフィルターされます。
編集（未実装）

2.2 詳細

npm アクセスは常に現在のレジストリに対して直接動作します。追加のレジストリ構成は --registry= <registry url> を使用してコマンドラインから実行できます。

スコープ外のパッケージは常にパブリックです。

スコープ付きパッケージはデフォルトで制限されていますが、npm public --access=public を使用してパッケージをパブリックとして公開したり、最初の公開後に npm access public を使用してアクセスをパブリックに設定したりすることができます。

パッケージのアクセス権限を設定する権限が必要です。

1. あなたはスコープなしまたはスコープ付きパッケージの所有者です

2. あなたはスコープを所有するチームの一員です。

3. チームメンバーとして、または直接所有者として、パッケージへの読み取りおよび書き込みアクセスが許可されています。

2 要素認証を有効にしている場合は、2 要素証明を求めるプロンプトが表示されるか、--otp=... オプションを使用してコマンドラインで指定する必要があります。

アカウントに料金が支払われていない場合、 --access=public を使用しない限り、スコープ内のパッケージを公開しようとすると、HTTP 402 ステータスコード (論理的には十分) で失敗します。

チームとチームメンバーの管理は、npm tea コマンドを通じて行われます。

3、npm追加ユーザー

3.1 説明

指定されたレジストリに新しいユーザーを作成し、資格情報を .npmrc ファイルに保存します。レジストリが指定されていない場合は、デフォルトのレジストリが使用されます。

auth-type がLegacyの場合、ユーザー名、パスワード、電子メールがプロンプトから読み取られます。

認証タイプ

デフォルト：「ウェブ」
タイプ: 「レガシー」または「Web」

ログイン時に使用する認証戦略。OTP 構成が指定されている場合、この値は常にレガシーに設定されることに注意してください。

4、npm監査

次のようにコマンドを使用します。

npm audit [fix|signatures]

4.1 はじめに

Audit コマンドは、プロジェクト内で構成されている依存関係の説明をデフォルトのレジストリに送信し、既知の脆弱性のレポートを要求します。脆弱性が見つかった場合は、影響と適切な是正措置が計算されます。fix 引数を指定すると、修正がパッケージツリーに適用されます。

脆弱性が見つからない場合、コマンドは終了コード 0 で終了します。

一部の脆弱性は自動的に修正できないため、手動による介入やレビューが必要になることに注意してください。また、npm Audit fix は本格的な npm install をバックグラウンドで実行するため、インストーラーに適用される設定はすべて npm install にも適用されることにも注意してください。そのため、npm Audit fix --package-lock-only のようなものは期待どおりに機能します。

デフォルトでは、脆弱性が見つかった場合、監査コマンドはゼロ以外のコードで終了します。CI 環境では、コマンドが失敗する原因となる最小脆弱性レベルを指定するために --audit-level パラメーターを含めると便利な場合があります。このオプションはレポート出力をフィルター処理せず、コマンドの失敗しきい値を変更するだけです。

パッケージのセキュリティが次のようになった場合:

対応する安全でないパッケージがある場合、以下に示すように、次のパッケージの重大度レベルは「高」になります。

4.2 監査署名

パブリック npm レジストリ、または署名をサポートするレジストリからダウンロードされたパッケージの整合性を確保するために、npm CLI を使用して、ダウンロードされたパッケージのレジストリ署名を検証できます。

レジストリの署名は、次のコマンドを使用してaudit確認できます。

npm audit signatures

npm CLI は、次の規則に従っている場合、レジストリ署名とレジストリによって提供される署名キーをサポートします。

1. dist オブジェクトで署名されたパッケージの各リリースバージョンの提供

例: lodash v4.17.21

lodash - npm

https://registry.npmjs.org/ +「パッケージ名」+対応するバージョン番号で、対応する署名を確認できます。

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 または簡略化された拡張 ISO 8601 形式: YYYY-MM-DDTHH:mm:ss.sssZ
keydid: 公開鍵の sha256 フィンガープリント
keytype: npm CLI は現在、 ecdsa-sha2-nistp256
scheme: npm CLI は現在、 ecdsa-sha2-nistp256
key:base64でエンコードされた公開鍵

4.3 動作例

プロジェクトの脆弱性をスキャンし、脆弱な依存関係の互換性アップデートを自動的にインストールします。

npm audit fix

変更せずに node_modules 実行し audit fix、pkglock を更新するには:

npm audit fix --package-lock-only

更新をスキップ devDependencies:

npm audit fix --only=prod

audit fix 最上位の依存関係に、SemVer 互換の更新だけでなく、SemVer のメジャーアップデートをインストールさせます。

npm audit fix --force

ドライランを実行して audit fix 動作を確認し、インストール情報を JSON 形式で出力します。

npm audit fix --dry-run --json

詳細な監査レポートを JSON 形式で取得します。

npm audit --json

監査は、結果に中レベル以上の脆弱性が含まれている場合にのみ失敗します。

npm audit --audit-level=moderate

4.4 構成

`audit-level`

デフォルト: null
種類：空、「情報」、「低」、「中」、「高」、「重大」、または「なし」

npm audit ゼロ以外の終了コードで終了するための最小脆弱性レベル。

`dry-run`

デフォルト: false
タイプ: ブール値

これは、npm に変更を加えたくないことを意味し、npm は変更内容のみを報告する必要があります。これは、ローカルインストールを変更する任意のコマンド ( 、、、など) に渡すinstallことupdateがdedupeできuninstall ます pack 。 publish

dist-tags注: この機能は、などowner の他のネットワーク関連コマンドではサポートされていません。

`force`

デフォルト: false
タイプ: ブール値

残念な副作用、一般的なバグ、不必要なパフォーマンスの低下、悪意のある入力に対するさまざまな保護が削除されます。

グローバルインストールで非 npm ファイルの破損を許可します。
npm version クリーンでない git リポジトリ上でコマンドが動作できるようにします。
npm cache clean キャッシュフォルダーの削除を許可します。
engines 別のバージョンが必要であることを宣言するパッケージを npm でインストールできるようにします。
有効な場合でも、 engines 異なるバージョンを必要とする宣言を含むパッケージのインストールを許可します。node--engine-strict
npm audit fix 宣言した依存関係の範囲を超えるモジュールのインストールを許可します (SemVer の主要な変更を含む)。
公開されたパッケージのすべてのバージョンの非公開を許可します。
競合するpeerDependencyをルートプロジェクトにインストールできるようにします。
のときに npm init 暗黙的に設定されます --yes。
npm pkg 既存の価値観の破壊を許可する
(単一のバージョンだけでなく) パッケージ全体を非公開にすることができます。

何をしたいのか明確なアイデアがない場合は、このオプションを使用しないことを強くお勧めします。

`json`

デフォルト: false
タイプ: ブール値

通常の出力の代わりに JSON データを出力するかどうか。

その中で npm pkg set 、 JSON.parse() を使用してコレクション値を解析してから、に保存できます package.json。

すべての npm コマンドがサポートしているわけではありません。

`package-lock-only`

デフォルト: false
タイプ: ブール値

true に設定すると、現在の操作ではのみが使用され package-lock.json、は無視されます node_modules。

の場合 update、これは依存関係package-lock.jsonを確認してダウンロードするのではなく、を更新することだけを意味しますnode_modules 。

の場合 list、これは、出力がのコンテンツpackage-lock.json ではなく説明のツリーに基づくことを意味します。node_modules

`omit`

NODE_ENV デフォルト:環境変数が「production」に設定されている場合は「dev」、それ以外の場合は空です。
タイプ：「dev」、「optional」、「peer」（複数回設定可能）

ディスク上のインストールツリーから除外する依存関係のタイプ。

これらの依存関係は引き続き解決され、 package-lock.json または npm-shrinkwrap.json ファイルに追加されることに注意してください。これらはディスクに物理的にインストールされていないだけです。

パッケージタイプが --include と --omit リストの両方に表示される場合、それが含まれます。

生成された省略リストにが含まれる 'dev'場合、 NODE_ENV 環境変数はすべてのライフサイクルスクリプトに対してに設定されます 'production'。

`foreground-scripts`

デフォルト: false
タイプ: ブール値

preinstallインストールされたパッケージのすべてのビルドスクリプト (つまり、install および postinstall) スクリプトをフォアグラウンドプロセスで実行し、標準入力、出力、およびエラーをメインの npm プロセスと共有します。

これにより、通常、インストールの実行が遅くなりノイズも多くなりますが、デバッグには役立ちます。

`ignore-scripts`

デフォルト: false
タイプ: ブール値

true の場合、npm は package.json ファイルで指定されたスクリプトを実行しません。

を設定した場合 ignore-scripts、特定のスクリプトを実行することを明示的に意図したコマンド ( npm start、npm stop、npm restart、npm test など npm run-script) は引き続き意図したスクリプトを実行しますが、プレスクリプトやポストスクリプトは実行しないことに注意してください。

`workspace`

デフォルト:
型：文字列（複数設定可能）

この構成オプションで定義された実行ワークスペースのみでフィルタリングしながら、現在のプロジェクトの構成済みワークスペースのコンテキストでコマンドを実行できるようにします。

workspace 構成の有効な値は次のとおりです。

ワークスペース名
ワークスペースディレクトリへのパス
親ワークスペースディレクトリへのパス (そのフォルダー内のすべてのワークスペースが選択されます)

npm init コマンドに設定する場合、まだ存在しないワークスペースのフォルダーに設定してフォルダーを作成し、プロジェクト内に新しいワークスペースとして設定できます。

この値は、子プロセスの環境にはエクスポートされません。

`workspaces`

デフォルト: null
タイプ: null またはブール値

true に設定すると、構成されているすべての ワークスペースのコンテキストでコマンドが実行されます。

これを明示的に false に設定すると、 install このようなコマンドはワークスペースを完全に無視します。明示的に設定されていない場合:

node_modules ツリー上で実行されるコマンド (インストール、更新など) は、ワークスペースをnode_modules フォルダーにリンクします。workspace - 他の操作 (テスト、実行、公開など) を実行するコマンドは、構成で 1 つ以上のワークスペースが指定されていない限り、ルートプロジェクトで実行されます。

この値は、子プロセスの環境にはエクスポートされません。

`include-workspace-root`

デフォルト: false
タイプ: ブール値

コマンドのワークスペースを有効にする場合は、ワークスペースルートを含めます。

false の場合、 workspace config で単一のワークスペースを指定するか、 workspaces フラグですべてのワークスペースを指定すると、npm はルートプロジェクトではなく、指定されたワークスペースでのみ実行されます。

この値は、子プロセスの環境にはエクスポートされません。

`install-links`

デフォルト: false
タイプ: ブール値

ファイルを設定する場合: プロトコルの依存関係は、シンボリックリンクを作成する代わりに、通常の依存関係としてパッケージ化およびインストールされます。このオプションはワークスペースには影響しません。

NPM共通コマンド(1)

1、npm

1.1 はじめに

1.2 依存関係

1.3 インストール方法

2、npmアクセス

2.1 コマンドの説明

2.2 詳細

3、npm追加ユーザー

3.1 説明

4、npm監査

4.1 はじめに

4.2 監査署名

4.3 動作例

4.4 構成

`audit-level`

`dry-run`

`force`

`json`

`package-lock-only`

`omit`

`foreground-scripts`

`ignore-scripts`

`workspace`

`workspaces`

`include-workspace-root`

`install-links`

おすすめ