Renovateの特徴と基本的な使い方(TypeScript・Node.js)

Posted at 2026-09-03

本記事の執筆にはAIを使用しています。

はじめに

Renovateの特徴、基本的な使い方、主要なコメントの記法を紹介します。
主にTypeScript・Node.jsのライブラリで使うことを想定し、 dependencies と peerDependencies の違いも扱います。

「Renovate」とは？

リポジトリ内の依存関係を検出し、更新するPRを自動で作成するツールです。

npmだけでなく、Docker、GitHub Actions、Gradle、Swift Package Managerなど、多くのパッケージマネージャーに対応しています。
GitHub、GitLab、Bitbucket、Azure DevOpsなどで利用できます。

環境

参照した公式ドキュメントのRenovate: 44.61.3
Node.js: 24.13.0
npm: 11.10.0

本記事では、GitHubのMend Renovate Appを使います。
Renovateは更新が速いため、設定するときは公式ドキュメントも確認してください。

特徴

依存関係の更新PRを自動で作成する

Renovateは package.json などを検出し、新しいバージョンがあればPRを作成します。
変更履歴、リリース日、更新の種類などがPR本文にまとまるため、手動で更新するより調査の手間を減らせます。

ロックファイルがある場合は、パッケージマネージャーを実行して一緒に更新します。
npm、Yarn、pnpmのいずれも利用できます。

設定の自由度が高い

packageRules を使うと、パッケージ名、依存関係の種類、更新の種類などを条件にできます。
条件ごとにPRのまとめ方、スケジュール、自動マージなどを変えられます。

例えば次のような運用ができます。

ESLint関連のパッケージを1つのPRにまとめる
パッチ更新のみ自動でマージする
メジャー更新はDependency Dashboardで承認してからPRを作る
新しいバージョンの公開後、数日待ってから更新する
平日の深夜だけブランチを作る

npm以外の依存関係もまとめて更新できる

Node.jsのリポジトリには、npmパッケージ以外のバージョンもあります。
Renovateなら、次のようなファイルも同じ設定で管理できます。

.nvmrc や .node-version のNode.js
package.json の engines や packageManager
Dockerfile のNode.jsイメージ
.github/workflows/*.yml のGitHub Actions
Dev ContainerのFeatureやDockerイメージ

モノレポの package.json や pnpm-workspace.yaml も自動で検出します。

Dependency Dashboardで更新を一覧できる

dependencyDashboard を有効にすると、検出した更新を1つのIssueで確認できます。
保留中の更新、作成済みのPR、エラーなどがまとまります。

チェックボックスを使い、PRの作成、再作成、リベースも指示できます。
PRの数が多いリポジトリほど便利です。

設定をプリセットとして共有できる

Renovateの設定は extends で継承できます。
公式プリセットだけでなく、組織や個人の共通設定もパッケージのように共有できます。

複数のリポジトリで、スケジュールやラベルなどを揃えたい場合に向いています。

基本的な使い方

GitHub Appをインストールする

GitHub MarketplaceからMend Renovate Appをインストールし、対象のリポジトリを選びます。

インストールすると、 Configure Renovate というオンボーディングPRが作成されます。
このPRをマージするまで、依存関係を更新するPRは作成されません。

オンボーディングPRの設定を確認し、必要に応じて編集してからマージします。
以降はRenovateが定期的にリポジトリを確認します。

社内ネットワークやプライベートレジストリへの接続が必要な場合は、Renovateをセルフホストする方法もあります。

最小構成を作る

リポジトリのルートに renovate.json を作ります。
オンボーディングPRを使う場合は、自動で作成されます。

renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"]
}

$schema を指定すると、対応するエディタで補完や設定値の検証が効きます。
config:recommended は、公式が推奨する設定のプリセットです。

設定ファイルには renovate.json5 も使えます。
設定内へコメントを書きたい場合は、JSON5を選ぶと便利です。

TypeScript・Node.jsライブラリ向けに設定する

次は、npmで管理するライブラリ向けの設定例です。

renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "dependencyDashboard": true,
  "labels": ["dependencies"],
  "minimumReleaseAge": "3 days",
  "packageRules": [
    {
      "description": "開発用パッケージのパッチ更新を自動マージする",
      "matchManagers": ["npm"],
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["patch"],
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "description": "peerDependenciesの範囲を広げる",
      "matchManagers": ["npm"],
      "matchDepTypes": ["peerDependencies"],
      "rangeStrategy": "widen"
    },
    {
      "description": "ESLint関連をまとめる",
      "matchManagers": ["npm"],
      "matchPackageNames": ["eslint", "/^@eslint/", "/^typescript-eslint$/"],
      "groupName": "ESLint"
    },
    {
      "description": "メジャー更新は承認後にPRを作る",
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true
    }
  ]
}

各設定の役割は次のとおりです。

設定	説明
`extends`	プリセットを継承する
`dependencyDashboard`	更新状況をまとめたIssueを作る
`labels`	RenovateのPRへラベルを付ける
`minimumReleaseAge`	公開直後のバージョンへ待機中のステータスを付ける
`packageRules`	条件に一致した依存関係へ設定を適用する
`matchManagers`	npmなど、対象のマネージャーを絞る
`matchDepTypes`	`dependencies` や `devDependencies` などに絞る
`matchUpdateTypes`	`major` 、 `minor` 、 `patch` などに絞る
`matchPackageNames`	対象のパッケージ名を絞る
`groupName`	複数の更新を1つのPRにまとめる
`automerge`	条件を満たした更新を自動でマージする
`dependencyDashboardApproval`	Dashboardで承認するまでPRを作らない
`rangeStrategy`	`package.json` のバージョン範囲をどう更新するか決める

automerge は、CIとブランチ保護ルールを整えてから有効にしてください。
Renovateは必須のステータスチェックが成功するまで待ちますが、必須チェックが設定されていないとテストなしでマージされる可能性があります。

設定を検証する

Renovate CLIの renovate-config-validator を使います。

$ npx --yes --package renovate -- renovate-config-validator

Mend Renovate Appを使っている場合は、 renovate/reconfigure ブランチで設定を変更する方法もあります。
Renovateが設定を検証し、結果をステータスチェックやPRのコメントで知らせます。

作成されたPRを確認する

PRでは、少なくとも次を確認します。

CIが成功しているか
リリースノートに破壊的変更がないか
package.json とロックファイル以外に意図しない変更がないか
ライブラリが対応するNode.jsのバージョンを変えていないか
peerDependencies の対応範囲が適切か

問題がなければ通常のPRと同じようにマージします。
マージ後、ほかのRenovate PRが必要に応じて更新されます。

TypeScript・Node.jsライブラリでのポイント

`dependencies` と `devDependencies` を分けて考える

ライブラリの利用者へインストールされる dependencies は、更新の影響が大きくなりやすいです。
一方、TypeScript、ESLint、Vitestなどの devDependencies は、主にライブラリの開発環境へ影響します。

最初は次のように運用すると安全です。

dependencies はCIの結果とリリースノートを確認して手動でマージする
devDependencies のパッチ更新だけ自動でマージする
メジャー更新はDependency Dashboardで承認する

慣れてから、自動マージする範囲を広げましょう。

`peerDependencies` は対応範囲を狭めない

公開ライブラリの peerDependencies は、利用者が使えるバージョンの範囲を表します。
単純に新しいメジャーバージョンへ置き換えると、古いバージョンを使う利用者がインストールできなくなることがあります。

rangeStrategy に widen を指定すると、既存の範囲を残したまま新しい範囲を追加します。

package.json

  "peerDependencies": {
-   "react": "^18.0.0"
+   "react": "^18.0.0 || ^19.0.0"
  }

ただし、新しいメジャーバージョンで実際に動くことはCIで確認してください。
型チェックとユニットテストだけでなく、対応する各メジャーバージョンを使ったテストを用意すると安心です。

npmマネージャーの rangeStrategy: "auto" も、 peerDependencies では基本的に範囲を広げます。
意図を設定へ残したい場合は、 widen を明示するとわかりやすいです。

パッケージマネージャーのバージョンを固定する

package.json の packageManager を指定すると、開発者とRenovateが同じバージョンを使いやすくなります。

package.json

{
  "packageManager": "npm@11.10.0"
}

npm、Yarn、pnpmで生成されるロックファイルには違いがあります。
ロックファイルの不要な差分を避けるためにも、パッケージマネージャーの種類とバージョンを揃えましょう。

Node.jsの対応範囲も管理する

公開ライブラリでは、実行に必要なNode.jsの範囲を engines で示します。

package.json

{
  "engines": {
    "node": ">=20"
  }
}

Renovateは engines 、 .nvmrc 、DockerイメージなどのNode.jsも更新できます。
ただし、開発環境のNode.jsを更新しただけで、ライブラリの最低対応バージョンまで上げる必要はありません。

例えば engines.node はNode.js 20以上のままにし、CIではNode.js 20、22、24をテストできます。

更新をまとめすぎない

すべての更新を1つのPRにまとめると、CIが失敗した原因を探しにくくなります。
関係が強いパッケージだけをまとめるのがおすすめです。

まとめやすい例は次のとおりです。

ESLintとそのプラグイン
Vitestと @vitest/*
TypeScriptと型チェックに使う周辺ツール
同じ提供元のパッケージ群

メジャーバージョンが異なる更新は、基本的に別のPRにします。

公開直後のバージョンを少し待つ

minimumReleaseAge を使うと、公開されてから指定期間が過ぎるまでステータスチェックが待機中になります。
PRは作成されますが、自動マージは待機期間が過ぎるまで行われません。
公開直後に取り下げられたバージョンや、すぐ修正版が出るケースを避けやすくなります。

一方で、セキュリティ修正の取り込みも遅れます。
待機期間は長くしすぎず、リポジトリの方針に合わせて決めてください。

主要なコメントの記法一覧

ここでは、ファイル内へ書く renovate: コメントを扱います。
Renovateが標準で検出しないバージョンを customManagers の正規表現で扱うときに使います。

コメントの構文はRenovateが固定しているものではありません。
matchStrings に指定した正規表現と、ファイル側のコメントを一致させる必要があります。
次の形は、公式ドキュメントでも使われている一般的な書き方です。

# renovate: datasource=<データソース> depName=<表示名> packageName=<検索名> versioning=<方式>

主要な項目は次のとおりです。

項目	必須	説明	例
`datasource`	必須	新しいバージョンを取得する場所	`npm` 、 `docker` 、 `github-tags` 、 `github-releases`
`depName`	どちらか	PRなどに表示する依存関係の名前	`Node.js`
`packageName`	どちらか	データソースで検索する実際の名前	`nodejs/node`
`versioning`	任意	バージョンの比較方法。省略時は `semver-coerced`	`node` 、 `docker` 、 `semver`
`depType`	任意	依存関係の種類	`runtime`
`extractVersion`	任意	タグからバージョン部分を取り出す正規表現	`^v(?<version>.*)$`
`registryUrl`	任意	参照するレジストリのURL	`https://registry.npmjs.org`
`currentDigest`	任意	現在のダイジェスト	`sha256:...`

depName または packageName のどちらかは必要です。
両方を指定した場合、 depName は表示名、 packageName は検索名として使えます。

Node.jsのバージョンを書く

例として、TypeScriptの設定ファイルにツールのバージョンを直接書いている場合を考えます。

tools.ts

// renovate: datasource=npm packageName=typescript
export const typescriptVersion = '5.9.2'

対応する customManagers を設定します。

renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "customManagers": [
    {
      "customType": "regex",
      "description": "TypeScriptファイル内のツールを更新する",
      "managerFilePatterns": ["/^tools\\.ts$/"],
      "matchStrings": [
        "// renovate: datasource=(?<datasource>[a-z-]+) packageName=(?<packageName>[^\\s]+)\\nexport const [A-Za-z]+Version = '(?<currentValue>[^']+)'"
      ]
    }
  ]
}

正規表現の名前付きキャプチャ currentValue が現在のバージョンです。
datasource と packageName は、直前のコメントから取得します。

正規表現マネージャーはRE2を使います。
後方参照と先読みは使えません。
また、正規表現は行単位ではなくファイル全体へ適用されます。

Dockerfileへ書く

Dockerfile

# renovate: datasource=github-tags depName=Node.js packageName=nodejs/node versioning=node
ARG NODE_VERSION=24.13.0

コメント記号はファイルに合わせて変えられます。
YAMLやDockerfileでは # 、TypeScriptでは // を使うと自然です。
その場合も、 matchStrings を同じ記号へ合わせてください。

コメントを使わず固定値を設定する

すべての依存関係が同じデータソースを使う場合は、コメントへ全項目を書く必要はありません。
datasourceTemplate や packageNameTemplate で固定できます。

renovate.json

{
  "customManagers": [
    {
      "customType": "regex",
      "managerFilePatterns": ["/^\\.tool-versions$/"],
      "matchStrings": ["nodejs (?<currentValue>[^\\s]+)"],
      "packageNameTemplate": "nodejs/node",
      "datasourceTemplate": "github-tags",
      "versioningTemplate": "node"
    }
  ]
}

標準のマネージャーが対応しているファイルには、 customManagers を追加しないでください。
例えば package.json 、 .nvmrc 、Dockerfile、GitHub Actionsは標準で対応しています。

PRのコメントでRenovateを操作できる？

Renovateは、Dependabotの @dependabot rebase のようなPRコメントコマンドを正式には提供していません。
PRへ @renovate rebase と書いても、通常は動きません。

代わりに、次の操作を使います。

やりたいこと	操作
PRをリベース・再試行する	PR本文の `rebase/retry` チェックボックスを選ぶ
PRをリベース・再作成する	PRへ `rebase` ラベルを付ける
複数のPRをまとめてリベースする	Dependency Dashboardのチェックボックスを選ぶ
保留中の更新PRを作る	Dependency Dashboardで対象の更新を選ぶ
同じ更新を無視する	通常のRenovate PRをマージせず閉じる
無視した更新を再作成する	Dependency Dashboardの `PR Closed (Blocked)` から選ぶ

rebase ラベルの名前は rebaseLabel で変更できます。
RenovateのリベースはGitの git rebase そのものではなく、ベースブランチを元に更新内容を作り直す処理です。

通常のPRを閉じた場合も、さらに新しいバージョンが公開されると別のPRが作成されることがあります。
グループ化したPRやロックファイルのメンテナンスなど、閉じても再作成されるPRもあります。

Renovateのブランチへ自分のコミットを追加すると、自動更新は止まります。
手作業を残したい場合はそのままマージし、捨てて作り直してよい場合だけ rebase/retry を実行してください。

よく使う設定

設定	用途
`schedule`	ブランチを作成する時間帯を制限する
`prConcurrentLimit`	同時に開くPR数を制限する
`prHourlyLimit`	1時間に作るPR数を制限する
`separateMajorMinor`	メジャー更新とマイナー更新を分ける
`separateMinorPatch`	マイナー更新とパッチ更新を分ける
`ignoreDeps`	指定した依存関係を更新しない
`enabledManagers`	利用するマネージャーを限定する
`reviewers`	PRのレビュアーを指定する
`assignees`	PRの担当者を指定する
`semanticCommits`	Conventional Commitsに合わせたコミットを作る
`lockFileMaintenance.enabled`	バージョン範囲内でロックファイル全体を更新する

PRが多すぎる場合は、まず関連パッケージのグループ化、 prConcurrentLimit 、Dependency Dashboardを検討します。
いきなりすべての更新を1つにまとめると、更新しにくい大きなPRになりがちです。

おわりに

Renovateを使うと、TypeScript・Node.jsライブラリの依存関係を継続して更新できます。
まずは推奨プリセットとDependency Dashboardから始め、CIが安定した更新だけ自動マージすると安全に運用できます

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Renovateの特徴と基本的な使い方(TypeScript・Node.js)

はじめに

「Renovate」とは？

環境

特徴

依存関係の更新PRを自動で作成する

設定の自由度が高い

npm以外の依存関係もまとめて更新できる

Dependency Dashboardで更新を一覧できる

設定をプリセットとして共有できる

基本的な使い方

GitHub Appをインストールする

最小構成を作る

TypeScript・Node.jsライブラリ向けに設定する

設定を検証する

作成されたPRを確認する

TypeScript・Node.jsライブラリでのポイント

dependencies と devDependencies を分けて考える

peerDependencies は対応範囲を狭めない

パッケージマネージャーのバージョンを固定する

Node.jsの対応範囲も管理する

更新をまとめすぎない

公開直後のバージョンを少し待つ

主要なコメントの記法一覧

Node.jsのバージョンを書く

Dockerfileへ書く

コメントを使わず固定値を設定する

PRのコメントでRenovateを操作できる？

よく使う設定

おわりに

参考リンク

`dependencies` と `devDependencies` を分けて考える

`peerDependencies` は対応範囲を狭めない