なぜ「社内ライブラリ」をGitHub Packagesで管理するのか？
エンジニアとして成長するにつれ、私たちは「同じコードを何度も書いている」ことに気づきます。認証ロジック、共通のUIコンポーネント、ロギングのユーティリティ…。これらをコピペで使い回すのは、技術負債の始まりです。
GitHub Packagesを活用したプライベートレジストリの運用は、あなたのコードを「ただのファイル」から「チームの資産」へと昇華させる魔法です。今回は、単なる設定手順を超えた「組織の開発生産性を最大化する基盤構築」の極意を伝授します。
—
1. 概念の理解：npmレジストリの「裏側」
通常、私たちが `npm install` する際、裏側ではレジストリ（npm registry）という巨大な倉庫へアクセスしています。GitHub Packagesは、その倉庫の入り口を「あなたのGitHub組織（または個人アカウント）」に限定し、認証を通した者だけがアクセスできるようにする「堅牢な金庫」だと考えてください。
成功への第一歩：.npmrc の正体
npmは、プロジェクトのルートにある `.npmrc` という設定ファイルを見て「どこからパッケージをダウンロードし、どこにアップロードするか」を判断します。ここに、あなたのGitHub認証情報を正しくマッピングすることが、すべての始まりです。
—
2. 構築の手順：社内ライブラリを公開するまでのロードマップ
ステップ1：パッケージをレジストリに向ける
あなたのライブラリの `package.json` を開いてください。ここで重要なのは、`name` フィールドのスコープ（`@owner/package-name`）です。
{
“name”: “@your-github-username/my-shared-lib”, // 必須：@の後にGitHubのアカウント名を入れる
“version”: “1.0.0”,
“publishConfig”: {
“registry”: “https://npm.pkg.github.com/” // 公開先をGitHub Packagesへ明示的に指定
}
}
ステップ2：認証の極意（パーソナルアクセストークンの発行）
GitHubの「Settings > Developer settings > Personal access tokens (classic)」から、以下の権限を持つトークンを発行してください。
- `repo`
- `read:packages`
- `write:packages`
※ここで発行したトークンは、決してコードと一緒にGitへコミットしてはいけません。ローカル環境では環境変数として扱うのが鉄則です。
—
3. 自動化の美学：GitHub ActionsによるCI/CD構築
手動での `npm publish` は、ヒューマンエラーの温床です。GitHub Actionsを使い、「タグを打ったら自動公開される」という堅牢なフローを構築しましょう。
`.github/workflows/publish.yml` を作成します。
name: Publish Package to GitHub Packages
on:
release:
types: [created] # 新しいGitHubリリースを作成した瞬間に発火
jobs:
publish:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write # パッケージ書き込み権限を明示的に付与
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: ’18’
registry-url: ‘https://npm.pkg.github.com’ # GitHub Packagesを指定
- run: npm install
- run: npm publish # 自動的に認証情報を引き継いで公開
env:
NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }} # GitHubが自動発行するトークンを使用
このフローの素晴らしい点は、「あなたが公開作業の細部を意識する必要がない」という点です。セマンティックバージョニング（v1.0.1→v1.1.0）を守ってリリースボタンを押すだけで、全社へ新しい機能が共有されます。
—
4. 現場で震えるほど役立つ運用ルール：セマンティックバージョニング
最後に、アーキテクトとして最も強調したいのが「バージョン管理の規律」です。
- PATCH (1.0.1): 互換性のあるバグ修正。
- MINOR (1.1.0): 互換性を保った機能追加。
- MAJOR (2.0.0): 破壊的変更（APIの変更など）。
このルールをチームで徹底してください。利用側（クライアント）の `package.json` で `^1.0.0` と指定していれば、チームメイトは安心してバグ修正を恩恵として受け取れます。逆に、MAJORバージョンを上げるときは、必ずチーム全員に通知する文化を作りましょう。
—
さあ、始めましょう
この仕組みを導入すれば、あなたは「コードを共有するためにチャットツールでファイルを送る」という非効率な時間から解放されます。
1. まずは小さな関数を1つだけパッケージ化する
2. `npm publish` のログを見て、成功体験を積む
3. 同僚に `@your-github-username/my-shared-lib` をインストールしてもらう
この小さな一歩が、いずれ組織全体の開発速度を劇的に向上させる巨大な歯車になります。何か詰まったら、いつでも戻ってきてください。私たちは、より速く、より賢くコードを書くためにここにいるのですから。