注: サイト管理者はそれぞれのサポートされているパッケージの種類を有効化あるいは無効化できるので、このパッケージの種類はインスタンスで利用できないかもしれません。 詳しくは、「Enterprise 向けのパッケージエコシステムサポートを設定する」を参照してください。
公開したnpmバージョンに対する制限
GitHub Packagesに公開したnpmパッケージのバージョンが1000を超える場合、使用中にパフォーマンスの問題やタイムアウトが発生することがあります。
サービスのパフォーマンスを向上させるため、将来的には1,000を超えるパッケージのバージョンをGitHubに公開できなくなります。 この制限に達しないバージョンであれば、今後も読み取り可能です。
この制限に達した場合は、パッケージのバージョンを削除するよう検討するか、サポートにお問い合わせください。 この制限が施行されるようになると、ドキュメントが更新され、これを回避する方法が記載される予定です。 詳細については、「パッケージを削除および復元する」または「GitHub Packages の概要」を参照してください。
GitHub Packages への認証を行う
GitHub Packages では、personal access token (classic)を使用した認証のみがサポートされています。 詳しくは、「個人用アクセス トークンを管理する」を参照してください。
非公開パッケージ、内部パッケージ、公開パッケージを発行、インストール、削除するには、アクセス トークンが必要です。
personal access token (classic) を使って、GitHub Packages または GitHub Enterprise Server API の認証を受けることができます。 personal access token (classic) を作成するときは、必要に応じてさまざまなスコープをトークンに割り当てることができます。 personal access token (classic) のパッケージ関連のスコープの詳細については、「GitHub Packagesの権限について」を参照してください。
GitHub Actionsワークフロー内でGitHub Packagesレジストリに認証を受けるには、以下の方法が使えます。
GITHUB_TOKEN
では、ワークフロー リポジトリに関連付けられているパッケージを発行します。read:packages
以上のスコープが設定された personal access token (classic) では、他のプライベート リポジトリ (GITHUB_TOKEN
ではアクセスできない) に関連付けられているパッケージがインストールされます。
personal access token
で認証を行う
GitHub Packages でパッケージを発行およびインストールするには、適切なスコープで personal access token (classic) を使う必要があります。 詳しくは、「GitHub Packages の概要」を参照してください。
npm で GitHub Packages に対して認証を行うには、ユーザーごとの ~/.npmrc ファイルを編集して personal access token (classic) を含めるか、コマンド ラインでユーザー名と personal access token を使って npm にログインします。
~/.npmrc ファイルに personal access token (classic) を追加して認証を行うには、プロジェクトの ~/.npmrc ファイルを編集して次の行を含めます。HOSTNAME は お使いの GitHub Enterprise Server インスタンス のホスト名に、TOKEN は personal access token に置き換えます。 存在しない場合は、新しい ~/.npmrc ファイルを作成します。
インスタンスで Subdomain Isolation が有効になっている場合:
//npm.HOSTNAME//:_authToken=TOKEN
インスタンスで Subdomain Isolation が無効になっている場合:
//HOSTNAME/_registry/npm/:_authToken=TOKEN
npm にログインして認証を行うには、npm login
コマンドを使用します。USERNAME は GitHub ユーザー名に、TOKEN は personal access token (classic) に、PUBLIC-EMAIL-ADDRESS はメール アドレスに置き換えます。
npm CLI バージョン 9 以上を使用していて、コマンド ラインを使用してプライベート レジストリにログインまたはログアウトしている場合は、ブラウザー経由で既定のログイン フローを使用する代わりに、プロンプトから認証の詳細を読み取る --auth-type=legacy
オプションを使用する必要があります。 詳細については、npm-login
を参照してください。
GitHub Packages が npm を使う場合の既定のパッケージ レジストリではなく、npm audit
コマンドを使いたい場合は、GitHub Packages への認証を行うときに、パッケージをホストする名前空間 (パッケージがホストされているリポジトリを所有しており、個人アカウントまたは Organization) で --scope
フラグを使うことをお勧めします。
インスタンスで Subdomain Isolation が有効になっている場合:
$ npm login --scope=@NAMESPACE --auth-type=legacy --registry=https://npm.HOSTNAME/
> Username: USERNAME
> Password: TOKEN
インスタンスで Subdomain Isolation が無効になっている場合:
$ npm login --scope=@NAMESPACE --auth-type=legacy --registry=https://HOSTNAME/_registry/npm/
> Username: USERNAME
> Password: TOKEN
パッケージの公開
注: パッケージ名とスコープには小文字のみを使用する必要があります。
既定では、パッケージは name
フィールドの package.json
ファイル で指定した GitHub リポジトリで公開されます。 たとえば、@my-org/test
という名前のパッケージは、my-org/test
GitHub リポジトリに公開することになります。 repository
フィールド の package.json
ファイルに含めることで、同じ GitHub リポジトリに複数のパッケージを公開できます。 詳しくは、「同じリポジトリへの複数パッケージの公開」をご覧ください。
プロジェクトのスコープマッピングは、プロジェクト内のローカル .npmrc
ファイルか、package.json
内の publishConfig
オプションを使って設定できます。 GitHub Packagesはスコープ付きのnpmパッケージのみをサポートしています。 スコープ付きのパッケージには、@NAMESPACE/PACKAGE-NAME
形式の名前が付いています。 スコープ付きのパッケージの先頭には常に @
記号が付いています。 スコープ付きの名前を使うには、package.json
で名前を更新する必要がある場合があります。 たとえば、ユーザー octocat
のパッケージ名が test
の場合、スコープ付きのパッケージ名は "name": "@octocat/test"
のように割り当てることになります。
パッケージを公開した後は、GitHub上でそのパッケージを見ることができます。 詳しくは、「パッケージの表示」を参照してください。
ローカルの .npmrc ファイルを使用したパッケージの公開
.npmrc ファイルを使用して、プロジェクトのスコープのマッピングを設定できます。 .npmrc ファイルで GitHub Packages の URL とアカウント所有者を使い、GitHub Packages がパッケージ要求のルーティング先を把握できるようにしてください。 .npmrc ファイルを使うことで、他の開発者がパッケージを GitHub Packages ではなく npmjs.org に誤って公開することを防止できます。
- GitHub Packagesに認証を受けてください。 詳細については、「GitHub Packages への認証」を参照してください。
package.json
ファイルと同じディレクトリで、.npmrc
ファイルを作成または編集して、GitHub Packages URL を指定する行と、パッケージがホストされている名前空間を含めます。NAMESPACE
を、プロジェクトを含むリポジトリを所有しており、ユーザー アカウントまたは Organization アカウントの名前に置き換えます。
サブドメイン分離が有効な場合:
@NAMESPACE:registry=https://npm.HOSTNAME
Subdomain Isolationが無効な場合:
@NAMESPACE:registry=https://HOSTNAME/_registry/npm
-
GitHub Packages でプロジェクトを見つけられるリポジトリに .npmrc ファイルを追加します。 詳しくは、「ファイルをリポジトリに追加する」を参照してください。
-
プロジェクトの
package.json
にあるパッケージの名前を確認します。name
フィールドには、スコープとパッケージの名前が含まれている必要があります。 たとえば、パッケージの名前が「test」で、"My-org" GitHub Organization に公開する場合、package.json
内のname
フィールドを@my-org/test
にする必要があります。 -
プロジェクトの package.json の
repository
フィールドを確認します。repository
フィールドは、GitHub リポジトリの URL と一致している必要があります。 たとえば、リポジトリの URL がgithub.com/my-org/test
である場合、repository フィールドはhttps://github.com/my-org/test.git
でなければなりません。 -
パッケージを公開してください。
npm publish
package.json
ファイル で の publishConfig
を使用したパッケージの公開
publishConfig
要素を package.json
ファイルで 使用して、パッケージを公開するレジストリを指定できます。 詳細については、npm ドキュメントの「publishConfig」を参照してください。
-
パッケージの
package.json
ファイルを編集して、publishConfig
のエントリを含めるようにします。 インスタンスで Subdomain Isolation が有効になっている場合:"publishConfig": { "registry": "https://npm. HOSTNAME/" },
インスタンスで Subdomain Isolation が無効になっている場合:
"publishConfig": { "registry": "https://HOSTNAME/_registry/npm/" },
-
プロジェクトの package.json の
repository
フィールドを確認します。repository
フィールドは、GitHub リポジトリの URL と一致している必要があります。 たとえば、リポジトリの URL がgithub.com/my-org/test
である場合、repository フィールドはhttps://github.com/my-org/test.git
でなければなりません。 -
パッケージを公開してください。
npm publish
同じリポジトリへの複数パッケージの公開
複数のパッケージを同じリポジトリに公開して
場合は、GitHub リポジトリの URL を、各パッケージの repository
フィールド の package.json
ファイル に含めます。 詳細については、npm ドキュメントの「package.json ファイルの作成」と「Node.js モジュールの作成」を参照してください。
リポジトリの URL が正しいことを確認するには、REPOSITORY
は発行したいパッケージを含むリポジトリの名前に、OWNER
はリポジトリを所有している GitHub の個人アカウントまたは Organization の名前に置き換えます。
GitHub Packages によって、パッケージ名ではなく URL に基づいて照合されます。
"repository":"https://HOSTNAME/OWNER/REPOSITORY",
パッケージのインストール
プロジェクトの package.json
ファイルに依存関係としてパッケージを追加することで、GitHub Packages からパッケージをインストールできます。 プロジェクトで package.json
を使用する方法について詳しくは、「package.json の利用」に関する npm のドキュメントをご覧ください。
デフォルトでは、パッケージは1つのOrganizationから追加できます。 詳しくは、「他の Organization からのパッケージのインストール」をご覧ください。
プロジェクトに .npmrc ファイルを追加して、パッケージをインストールするためのすべての要求が GitHub Packagesを経由するようにする必要もあります。 すべてのパッケージ要求を GitHub Packages 経由になるようにルーティングすると、npmjs.org のスコープ付きおよびスコープなしのパッケージをどちらも使用できるようになります。詳しくは、npm のスコープに関する npm のドキュメントをご覧ください。
- GitHub Packagesに認証を受けてください。 詳細については、「GitHub Packages への認証」を参照してください。
package.json
ファイルと同じディレクトリで、.npmrc
ファイルを作成または編集して、GitHub Packages URL を指定する行と、パッケージがホストされている名前空間を含めます。NAMESPACE
を、プロジェクトを含むリポジトリを所有しており、ユーザー アカウントまたは Organization アカウントの名前に置き換えます。
サブドメイン分離が有効な場合:
@NAMESPACE:registry=https://npm.HOSTNAME
Subdomain Isolationが無効な場合:
@NAMESPACE:registry=https://HOSTNAME/_registry/npm
-
GitHub Packages でプロジェクトを見つけられるリポジトリに .npmrc ファイルを追加します。 詳しくは、「ファイルをリポジトリに追加する」を参照してください。
-
インストールするパッケージを使用するように、プロジェクトの
package.json
を構成します。 GitHub Packages のためにパッケージの依存関係をpackage.json
ファイルに追加するには、@my-org/server
のように完全なスコープ付きのパッケージ名を指定してください。 npmjs.com のパッケージの場合は、@babel/core
またはlodash
のように完全な名前を指定してください。ORGANIZATION_NAME/PACKAGE_NAME
をパッケージの依存関係と置き換えます。{ "name": "@my-org/server", "version": "1.0.0", "description": "Server app that uses the ORGANIZATION_NAME/PACKAGE_NAME package", "main": "index.js", "author": "", "license": "MIT", "dependencies": { "ORGANIZATION_NAME/PACKAGE_NAME": "1.0.0" } }
-
パッケージをインストールします。
npm install
他のOrganizationからのパッケージのインストール
デフォルトでは、1つのOrganizationからのみGitHub Packagesパッケージを利用できます。 パッケージ要求を複数の Organization とユーザーにルーティングする場合は、 .npmrc ファイルに行を追加し、 HOSTNAME
は お使いの GitHub Enterprise Server インスタンス のホスト名に、NAMESPACE
は、プロジェクトを含むリポジトリを所有しており、個人アカウントまたは Organization の名前に置き換えます。
インスタンスで Subdomain Isolation が有効になっている場合:
@NAMESPACE:registry=https://npm.HOSTNAME
@NAMESPACE:registry=https://npm.HOSTNAME
インスタンスで Subdomain Isolation が無効になっている場合:
@NAMESPACE:registry=https://HOSTNAME/_registry/npm
@NAMESPACE:registry=https://HOSTNAME/_registry/npm
公式 npm レジストリを使用する
GitHub Packages を使用すると、registry.npmjs.com
の公式 npm レジストリにアクセスできます (GitHub Enterprise Server 管理者がこの機能を有効にしている場合)。 詳しくは、「公式 npm レジストリに接続する」をご覧ください。