npmのガイド：Node.jsパッケージマネージャー

JavaScriptは、WebサイトやWebアプリケーションの開発に関して最もよく使用される言語です。 多数のリソースが驚異的であり、さらに、利用可能なライブラリの数も驚異的です。

最初は、これらのライブラリは少なく、保守が簡単です。 ただし、すぐに十分な依存関係地獄が始まり、より成熟したソリューションが必要になります。

Node Package Manager（npm）を入力します。これは、Node.jsと組み合わせて最もよく使用されるJavaScriptパッケージマネージャーですが、独立して使用することもできます。 プロジェクトの依存関係を非常に細かく制御でき、オープンソースの世界に貢献するための優れた方法を提供します。

npm install <package name>を実行し、JavaScriptファイルに挿入するだけで開始できます。

特定のバージョンをインストールしたいですか？ 問題ない。 npm install <package name>@1.2.3実行します。

パッケージをグローバルにインストールしたいですか（MochaやAngular-CLIなど）？ 次のように-gを追加するだけです： npm install -g angular-cli mocha 。

確かに、ほとんどのユースケースはnpmのインストールで停止し、他に何も必要ありません。 ただし、npmには多くの追加機能があり、それらについて説明し、私が不可欠、本当に便利、または単に素晴らしいと思う機能を強調します。

CLIコマンド

CLIは、ユーザーがほとんどの時間をnpmとの対話に費やす場所であり、そのヘルプインターフェイスは実際に役立ちます。

ヘルプ（ npm help ）をクエリすると、オプションの配列全体が出力され、 npm help-search <searchText>を実行すると、npmマークダウンから直接検索結果のリストが表示されます。

目立つコアコマンドは次のとおりです。

• install ：npmで作業するときの必要性から、ここで言及されています。 新しいパッケージをローカルまたはグローバルにインストールするため（ -gを追加する場合）、またはpackage.jsonファイルにリストされている依存関係をインストールするために使用されます（詳細は後で説明します）。

• uninstall ：これも不可欠です。 これは、ローカルまたはグローバルにnode_modulesディレクトリから特定のパッケージをパージするために使用されます（ -gを追加する場合）。

• access ：これは、コンテキストnpm-organizationsおよびスコープ（プライベート）パッケージ内のnpmユーザー権限管理者の遊び場です。 真剣に強力なもの。 adduser 、 owner 、 teamなどと組み合わせて使用​​すると、誰が何にアクセスできるかをきめ細かく制御できます。

• bin ：パッケージは一体どこにインストールされていますか？ このコマンドを実行して、ファイルの絶対パスを確認します。

• cache ：npm left、right、centerからパッケージのインストールを開始する場合、このコマンドは非常に便利です。 ローカルにキャッシュされたパッケージのリストを表示するにはlsサブコマンドを使用して呼び出すか、キャッシュ内にあるすべてのパッケージをクリアするにはcleanサブコマンドを使用して呼び出します。 npmレジストリがまだ少し不安定だった頃、これは安定した環境に戻るため、またはnpm権限を適切に設定しなかったときにリセットするために不可欠でした。

• config ：後でさまざまな構成オプションについて説明しますが、このコマンドは主に、 set 、 get 、またはdeleteサブコマンドを使用して、ローカルまたはグローバル構成ファイルの構成プロパティを永続化することを扱います。

• dedupeまたはddp ：長期間にわたってプロジェクトで作業し、npmから直接パッケージをインストールする場合、このコマンドはローカルパッケージツリーをウォークし、依存関係を単純化しようとします。

• link ：独自のnpmパッケージを開発している場合、これにより、グローバルコンテキストへのシンボリックリンクを作成できるため、npmレジストリからグローバルにインストールされたかのようにテストできます。 たとえば、CLIがグローバルにインストールされているノードでアセンブリツールを作成している場合、最初にデプロイしなくても、このコマンドを実行してCLIの動作をテストできます。

• ls ：ツリー構造でパッケージの依存関係とその依存関係を視覚化するために使用されます。 見るのはかっこいいし、他のプロジェクトとの比較にも役立ちます。

• outdated ：これは、インストールされている依存関係の現在の状態と、それらが古くなっているかどうかを評価するために使用されます。 ルート依存関係リストが数百行の長さのプロジェクトでは、パッケージを手動でチェックすることはほぼ不可能です。 このコマンドに-g --depth=0を追加すると、グローバルにインストールされているパッケージも確認できます。

• publish ：このコマンドは、npm用の独自のパッケージを開発する場合に不可欠です。 名前が示すとおりに機能します。 パッケージをnpmレジストリに公開します。

• search ：これを使用して、3番目の引数で提供されたテキストを含むすべてのパッケージのレジストリを検索します。

• shrinkwrap ：要するに、このコマンドを使用すると、パッケージ内の特定の依存関係バージョンを順番にロックダウンできるため、緩和されたsemver（セマンティックバージョニング）番号によって本番コードが破損することはありません。

• star ：あなたはあなたが使っているパッケージが本当に好きですか？ このコマンドを使用して、ターミナルから直接感謝の気持ちを示します。これは、npmレジストリのパッケージのページに反映されます。

• update ：これは通常、 outdatedコマンドに従って古いパッケージを更新します。

• version ：これにより、 package.jsonバージョンプロパティをバンプし、gitタグをすべて1つで実行するための省略形が提供されます。

これらのコマンドのほとんどはサブコマンドや構成をとることができ、このリストは決してCLIに関するすべての議論ではないことに注意してください。

npm-config

構成はnpmの主要な部分であり、構成変数を設定する方法は複数あります。

CLIおよび環境変数による構成

まず、ターミナルからCLIを介して構成を設定できます。

通常、次のようになりますnpm <command> --<configuration option> [<optional value>] 。

値が指定されていない場合、オプションはデフォルトでtrueに設定されます。

たとえば、スコープ付き（プライベート）npmパッケージで作業していて、それをパブリックパッケージとして公開することにしたとします。

これは、 publishコマンドに--access=publicを追加することで簡単に実行できます。 プロパティをパブリックに指定しなかった場合、デフォルトは制限されます（プライベート）。

このような他のコマンドに追加された構成はどこでも持続するわけではないため、CLIを介して構成の配列を設定するのは面倒になる可能性があります。

そのような場合は、環境変数を使用して構成を設定する方がよい場合があります。

npm_config_プレフィックスが設定された環境変数は、npmの構成に使用されます。

次に例を示しexport npm_config_registry=localhost:4321は、レジストリ構成オプションをグローバルに設定し、npmが実行されると、ポート4321のlocalhostにあるnpmレジストリを使用します。

npmrcファイルによる構成

特別な.npmrcファイルを使用して構成オプションを設定することもできます。このファイルは、要件に応じてさまざまなレベルで設定できます。

• プロジェクトレベル：プロジェクトのコードのルートとそのpackage.jsonファイル（通常はpath/to/project/.npmrc
• ユーザーレベル：特定のユーザーのアカウントを構成するディレクトリ（通常は~/.npmrc
• グローバルレベル：npmがグローバル構成を検索するディレクトリ（通常は$PREFIX/etc/npmrc
• 組み込みレベル：注意してください。 この構成はグローバルであるだけでなく、npmソースコードの一部でもあります。ベストプラクティスでは、維持する責任のないコードを変更しないことをお勧めします（実際には要求されます）。 通常、 /path/to/npm/npmrcます。

.npmrcファイルの構成設定は、次の形式のコマンドを実行することにより、CLIを使用して変更および永続化できます： npm config set <key> <value> 。

たとえば、 npm config set access publicを実行して、スコープ（プライベート）パッケージの公開構成を永続的にパブリックにすることができます。

デフォルトでは、このコマンドは構成をローカルに永続化します（上記のユーザーレベルの構成）が、 -gを追加してグローバルに永続化することができます。

永続化された構成をプロジェクトレベルまたは組み込みレベルで行う必要がある場合は、テキストエディターを使用して.npmrcファイルを変更する必要があります。

package.jsonによる構成

最後に、構成はpackage.jsonファイルから設定できます。 ただし、これはめったに使用されません（明示的に必要な場合にのみ使用する必要があります）。これは、プロジェクトレベルの.npmrcファイルがパッケージ構成を設定するために従来から好まれている場所であるためです。

注目すべき構成設定

• access ：前述のように、権限を設定するために使用されます。

• always-auth ：この設定はデフォルトでfalseに設定されていることに注意してください。 trueに設定されている場合、npmはレジストリに接続するときに常に認証を要求します。

• ca ：デフォルトはnpm認証局（CA）です。 nullに変更して、既知のレジストラのみへのアクセスを許可するか、特定のCA証明書へのアクセスのみを許可するように変更できます。 この設定は、 cafile 、 cert 、およびstrict-sslとともに使用されることはめったにありませんが、npmのセキュリティと信頼性の側面について話し、インストールするパッケージが期待するソースからのものであることを安心して確認できます。

• color ：これはデフォルトでtrueに設定され、ttyファイル記述子で許可されているstdoutに色を付けることで、端末の標準的な暗さから抜け出します。 falseに設定すると、端末は鈍いままになります。 alwaysに設定すると、常にカラーで出力されます。

• depth ：この設定では、実行の深さを割り当てることにより、 lsやoutdatedなどの再帰コマンドで表示される内容をきめ細かく制御できます。 値0は依存関係の最初のレベルのみを評価しますが、無限大（デフォルト）はすべてのレベルの依存関係を評価します。 このルールの例外は、 outdatedで使用する場合です。 その場合、より適切な出力を保証するために、無限大は0として解釈されます。

• dev ：これはデフォルトでfalseに設定されていますが、trueに設定されている場合（ npm installを実行する場合）、 package.jsonファイル内のすべての開発依存関係が通常の依存関係とともにインストールされます。

• dry-run ：この設定がtrueに設定されている場合、npmはパッケージに変更を加えませんが、代わりに何が行われたかを通知します。 これは、 dedupeやupdateなどの特定のコマンドを実行するときに非常に役立ちます。

  

• git-tag-version ：デフォルトでtrueに設定されています。 この設定は、 npm versionコマンドの実行時にgitのバージョンにタグを付けます。 gitでバージョンをタグ付けした大規模なプロジェクトのパッケージマネージャーとしてnpmを使用している場合は、時間を節約でき、 package.jsonファイルを更新することを忘れないでください。

• loglevel ：デフォルトでは、これはwarnに設定されており、npmコマンドを実行するとエラーと警告が出力されます。 その他の設定には、出力を提供しないsilentが含まれます。 error 。エラーのみを出力に記録します。 http 、httpリクエストエラーのみをアナウンスします。 info 、有益な出力が必要な場合）; verbose 、ほとんどすべてをログに記録します。 そしてsilly 、それは名前が示唆するように、愚かな量の出力を与え、次にいくつかを与えます。

• production ：これがtrueに設定されている場合、npmはそれに応じて動作し、すべてのコマンドを本番モードで実行します。 これは、開発またはオプションの依存関係がインストールされず、開発関連のタスクが実行されないことを意味します。

• rollback ：trueに設定すると、失敗したインストールはすべて削除されます。 これは、依存関係のインストールが失敗した場合に便利です。 ロギングのレベルに応じて、失敗したインストールを確認し、それらをメモして、rollbackオプションをtrueに設定してnpm installコマンドを実行できるはずです。 次に、メモとドライランインストール（上記のとおり）を使用して、問題をデバッグできます。

• save : When installing a package directly from the registry, you can append 、コマンドに–saveを追加して、インストールされたパッケージをpackage.json file. For example, to the command which will add the installed package to the dependencies option in theます。 file. For example, npminstalllodash`は依存関係にlodashを追加します。

• save-dev ：構成の保存オプションと同様に、パッケージのインストール時に--save-devを追加すると、 package.jsonファイルのdevDependenciesオプションに追加されます。

• save-optional ：save configurationオプションと同様に、パッケージをインストールするときに--save-optionalを追加すると、 package.jsonファイルのoptionalDependenciesオプションに追加されます。

• save-exact ：パッケージをインストールする場合、 save 、 save-dev 、 save-optionalオプションは、インストールされたパッケージをsemver range演算子を使用してそれぞれのプロパティに挿入することにより、 package.jsonファイルを変更します。 値trueで'save-exact'構成設定を呼び出す場合、上記の設定の1つと組み合わせて、特定のバージョン番号が使用され、semver範囲は無視されます。

• save-prefix ：これは、 save 、 save-dev 、またはsave-optionalを使用するときにsemver範囲演算子を設定します。 デフォルトは^で、インストール時にパッケージのマイナーアップグレードを実行できます。 これは、任意の有効なプレフィックス付きsemver範囲演算子に設定できます。

• tag-version-prefix ：従来のデフォルトはvで、 npm versionを実行するときにgitタグバージョンに追加されるものを指定します。

npmを使用したnpmの更新

npmを使用して自分自身を更新することもできます。

npm install -g npm@latestを実行するだけで、npmが最新の安定したリリースに更新されます。 Node.jsの各バージョンには特定のバージョンのnpmが付属していることに注意することが重要です。私の経験では、そのペアリングをあまりいじらないでください。

結局のところ、意図したとおりにペアリングを続けることをお勧めします。

npmをスタンドアロンツールとして使用する場合は、選択したバージョンを使用することの意味を理解してください。 nvmと呼ばれる同じシステム上で異なるNode.jsバージョン（そしてnpmバージョン）を管理するための優れたツールがあります。

package.jsonファイル

package.jsonファイルは、すべてをリンクする重要な要素です。

これは、パッケージをnpmレジストリに公開するための要件であり、依存関係の管理部分が機能する場所です。

「名前」と「バージョン」の2つの必須フィールドがあり、これらのプロパティを合わせて一意の識別子にする必要があります。

名前フィールドは、命名に関するnpmのドキュメントで定義されているように、特定のルールに準拠する必要があり、バージョンフィールドはsemverの仕様に従う必要があります。

さらに、1マイルの長さの依存関係のリストを作成し、semverバージョンと範囲演算子を使用して、それぞれに使用する特定のバージョンを定義できます。 その他の注目すべきプロパティのリストは次のとおりです。

"主要"

「main」は、アプリケーションへのエントリポイントを定義します。デフォルトはindex.jsです。 慣習やフレームワークに応じて、 app.jsまたはmain.jsの場合があります。 もちろん、好きなように作ることができます。

「スクリプト」

これは過小評価されているプロパティです。

まず、事前公開で何かを行うために使用できます。

次に、ビルドタスク（gulpまたはgruntで定義）、他の依存関係のインストールのトリガー（bowerなど）、webpackを使用した開発サーバーの起動など、頻繁に使用されるコマンドの配列をエイリアスできる場所を提供します。一連のbashコマンドを実行します。

「依存関係」

このプロパティは、互換性のあるsemver番号とともに、アプリケーションに必要なパッケージのリストです。 ローカルパッケージをインストールするときにターミナルから変更できるため、これは注目に値するプロパティです。

これは、 npm installコマンドの最後に--save （または省略形の-S ）を追加することで実行されます。

これを行うと、新しくインストールされたパッケージがpackage.jsonファイルの依存関係のリストに追加されます。

同様に、 npm uninstallコマンドの実行時に--saveを追加することで依存関係を削除することもできます。

各依存関係のsemverバージョン管理パターンとその意味を知っておくことが重要です。

semverルールが厳しすぎると、新機能や改善点を失うことになりますが、semverルールが緩和されすぎると、パッケージの最新バージョンをラインに沿ってインストールできます。

壊れたパッケージのインストールは、特にパッケージの縮小バージョンが使用されている場合、解決が非常に難しいことが判明する可能性があります。

「devDependencies」

依存関係プロパティとは別に、「devDependencies」プロパティを使用すると、開発フェーズでのみ使用され、本番ビルドには必要のない依存関係を定義できます（ESLint、grunt-contribパッケージ、Protractorなど）。 依存関係の場合と同様に、このプロパティは、 npm installコマンドまたはnpm uninstallコマンドの最後に--save-dev （または省略形の-D ）を追加することにより、ターミナルから変更できます。 依存関係で説明したのと同じ注意がバージョン管理にも適用されます。

"置き場"

ここで、CLIユーティリティへのパスなど、パッケージの実行可能ファイルを指定できます。 このプロパティは、パッケージのインストール時に実行可能ファイルへのローカルまたはグローバルのシンボリックリンクを作成するようにnpmに指示します。

「config」

前に説明したように、これはpackage.jsonファイルを介して構成設定を定義する場所です。

"プライベート"

trueに設定すると、npmはパッケージの公開を拒否します。

これをアクセス構成設定と混同しないでください。

これは、 package.jsonとともにnpmを利用するプロジェクトがある場合に便利な設定ですが、スコープ付きまたはパブリックのいずれかでnpmレジストリに公開することを目的としていません。

意図が変わった場合は、設定をfalseに変更するだけで、パッケージを公開できるようになります。

カスタムプロパティ

package.jsonファイルは、名前がまだ定義または予約されていない限り、カスタムプロパティも受け入れます。

独自のnpmパッケージの開発

npmエコシステムは、世界中の何千もの異なる開発者によって書かれたパッケージで満たされています。 それぞれが何らかの問題を解決し、抽象化を提供したり、何かの実装を提示したりします。

ある時点で、あなたも共有する独自のパッケージを開発したいと思うでしょう。

まず、「name」と「version」の最低限必要なプロパティを使用してpackage.jsonファイルを作成し、次に「main」プロパティを作成してエントリポイントを指定する必要があります（例：index.js）。

そのindex.jsファイルにコードを記述し、npmユーザーアカウントでログインするか、ターミナルから新しいユーザーを作成すると、npmレジストリに公開する準備が整います。

パッケージはパブリックまたはプライベートにすることができます。

公開パッケージは無料で公開でき、誰でも利用できます。

スコープ付きパッケージと呼ばれるプライベートパッケージは、プライベートモジュールユーザーに支払いを行った場合にのみ公開でき、パッケージ名の前に付けられた個別の@username/で識別できます。

スコープパッケージは、 --access=publicを指定してpublishコマンドを呼び出すことで公開することもできます。

さらに、パッケージのコードベースの拡張と改善にもう少し時間を費やし、新しいバージョンを公開するときは、 package.json内のパッケージのバージョンを（semverのルールと規則に従って）変更するだけです。ファイルを入力し、 npm publishと入力します。

コマンドラインインターフェイスを使用して、 npm version <update_type>を呼び出すこともできます。ここで、update_typeは、semverで説明されているように、 patch 、 minor 、 majorのいずれかであり、これにより、 package.jsonファイルのバージョン番号が自動的にインクリメントされます。

npm組織

繰り返しになりますが、これに関するnpmのドキュメントは優れており、彼らの言葉を繰り返すだけでは無駄です。

npmのコンテキストで組織について言えることは、組織が非常にきめ細かく、正しく管理されている場合、1つの名前でスコープパッケージまたはパブリックパッケージに取り組んでいる大規模なチームや個人を非常に適切に管理および制限できることです。

習得するのは複雑ですが、非常にやりがいがあります。

npmの力

最終的に、npmが提供するドキュメントは広範であり、詳細については参照する必要がありますが、この記事では、npmの素晴らしさを伝える、基本的な機能とより高度な関連機能の両方の有用な概要を提供します。

すべてのものと同様に、強い意見が存在し、多くの欠点を見つけることができます。 しかし、npm（またはノード）を試したことがない場合は、飛び込んで自分で調べてみてください。 思った以上に楽しめる可能性があります。

npmに関するさらに興味深い記事については、npmとBrowserifyでのScala.jsの使用を読むことを検討してください。