Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • コマンドライン
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリー
    • 継続的統合
  • 言語サポート
    • Node.js
    • Ruby
      • Rails のサポート
      • Bundler の使用
    • Python
      • Python でのバックグランドジョブ
      • Django の使用
    • Java
      • Maven の使用
      • Java でのデータベース操作
      • Java の高度なトピック
      • Spring Boot の使用
    • PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres Getting Started
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
    • Heroku Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
    • コンプライアンス
  • Heroku Enterprise
    • Private Space
      • インフラストラクチャネットワーキング
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
    • シングルサインオン (SSO)
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Integrating with Salesforce
  • 言語サポート
  • Node.js
  • Heroku の Node.js サポート

Heroku の Node.js サポート

日本語 — Switch to English

最終更新日 2022年10月19日(水)

Table of Contents

  • アクティベーション
  • Node.js ランタイム
  • Node.js バージョンの指定
  • npm バージョンの指定
  • Yarn バージョンの指定
  • ビルド動作
  • ビルドプロセスのカスタマイズ
  • キャッシュの動作
  • ランタイムの動作
  • デフォルトの Web プロセスタイプ
  • 警告
  • アドオン
  • 複数の buildpack による動作
  • 理解を深める

このドキュメントでは、Node.js アプリケーションの認識と実行に関連した Heroku の一般的な動作について説明します。アプリケーションのデプロイ方法に関する詳しい説明は、「Heroku スターターガイド (Node.js)」 を参照してください。

アクティベーション

Heroku の Node.js buildpack が使用されるのは、アプリケーションのルートディレクトリに package.json​ ファイルがある場合だけです。

Node.js ランタイム

Node のバージョンは、GitHub によって一般に普及しているセマンティックバージョニング規約である semver​ に準拠します。semver では MAJOR.MINOR.PATCH​ 形式のバージョンスキームが使用されます。

  • MAJOR​ は互換性のない API 変更を示します
  • MINOR​ は下位互換性のある方法で追加される機能を示します
  • PATCH​ は下位互換性のあるバグ修正を示します

サポートされているランタイム

Heroku では、現在の​バージョンの Node.js だけでなく、すべてのアクティブな LTS​ (長期サポート) バージョンがサポートされています。Heroku では、Node チームからの正式リリースの 24 時間以内に新規リリースがサポートされる予定です。次の Node.js のリリーススケジュールに示されているように、Heroku の現在サポートされている Node.js バージョンは 16.x​、18.x​、19.x​ です。

Node のリリーススケジュール

その他の使用可能なランタイム

Heroku は標準の Ubuntu Linux スタックに基づいているため、ほとんどの Node バージョン (>= 0.10.0​) をプラットフォームで実行できます。ただし、buildpack のテストおよびサポートは、アクティブな LTS および安定リリースに重点が置かれています。

Node.js バージョンの指定

常に、開発やテストで使用しているランタイムに一致する Node.js バージョンを指定します。ローカルのバージョンを検索するには、次のようにします。

$ node --version
v18.7.0

最初に、アプリケーションが heroku/nodejs​ buildpack を使用していることを確認します。

$ heroku buildpacks
=== issuetriage Buildpack URLs
1. heroku/nodejs

Node バージョンがエンジンで指定されない場合、Heroku-20 以降では 18.x​ リリースが使用され、Heroku-18 では 16.x​ が使用されます。

次に、package.json​ の engines​ セクションを使用して、Heroku で使用する Node.js のバージョンを指定します。'v’ を削除してバージョン番号のみを保存します。

{
  "name": "example-app",
  "description": "a really cool app",
  "version": "1.0.0",
  "engines": {
    "node": "18.x"
  }
}

Node から最新のパッチ更新を取得するために、パッチに x​ を使用することをお勧めします。また、マイナー範囲 (18.7​ など) または正確なバージョン (16.19.1​ など) を指定することもできます。

Node では、サポートされているすべてのメジャーバージョンで定期的なセキュリティリリースが行われるため、セキュリティ更新を自動的に取得するためにメジャー範囲 (18.x​ など) を指定することをお勧めします。

npm バージョンの指定

Node.js は npm にバンドルされているため、ほとんどの場合は npm バージョンを別途指定する必要はありません。ただし、ローカルで意図的に異なるバージョンの npm を使用している場合、Heroku で同じバージョンの npm を指定することができます。

{
  "name": "example-app",
  "description": "a really cool app",
  "version": "0.0.1",
  "engines": {
    "npm": "7.x"
  }
}

Yarn バージョンの指定

アプリケーションのルートに package.json​ と共に yarn.lock​ ファイルがある場合、Heroku では Yarn をダウンロードしてインストールし、これを使用して依存関係をインストールします。ローカルで使用しているバージョンを指定して、Heroku で同じバージョンが使用されるようにします。

{
  "name": "example-app",
  "description": "a really cool app",
  "version": "1.0.0",
  "engines": {
    "yarn": "1.x"
  }
}

ビルド動作

Node プロジェクトは Yarn パッケージマネージャ​または npm パッケージマネージャ​のいずれかを使用してビルドされます。

yarn.lock​ ファイルがプロジェクトのルートに検出された場合、依存関係のインストールとスクリプトの実行に Yarn が使用されます。それ以外の場合は、npm が使用されます。yarn.lock​ をプロジェクトにチェックインした場合に、Heroku でのビルドに npm を使用する場合は、yarn.lock​ を .slugignore​ ファイルに追加します。

パッケージのインストール

デフォルトでは、Heroku は package.json​ の dependencies​ および devDependencies​ に記載されているすべての依存関係をインストールします。

インストールおよびビルドステップ​を実行した後、 Heroku はアプリケーションをデプロイする前に、devDependencies​ に宣言されているパッケージを取り除きます。

Heroku では、package-lock.json​ または yarn.lock​ のロックファイルを使用して、期待される依存関係ツリーをインストールするため、これらのファイルを git にチェックインして環境全体の依存関係バージョンを同じにしてください。npm を使用している場合、Heroku では npm ci​ を使用してビルド環境を設定します。

npm install の使用

ビルド環境を作成するために、npm ci​ ではなく npm install​ を使用する場合、USE_NPM_INSTALL​ 環境変数を使用して、buildpack に認識させることができます。これは、次を実行することによって行うことができます。

$ heroku config:set USE_NPM_INSTALL=true

npm install​ を使用する場合、Heroku キャッシュを使用​してビルドを高速化する必要があります。npm install​ を使用しない場合、先に進んでビルドキャッシュを無効化できます。

$ heroku config:set NODE_MODULES_CACHE=false

dependencies のみのインストール

次の環境変数​を設定することによって、dependencies​ のみをインストールするよう Heroku に指示することができます。

  • NPM_CONFIG_PRODUCTION=true​ (npm​ の場合)
  • YARN_PRODUCTION=true​ (Yarn v1​ の場合)
$ heroku config:set NPM_CONFIG_PRODUCTION=true YARN_PRODUCTION=true

プルーニングのスキップ

別の buildpack またはランタイムに devDependencies​ に宣言されたパッケージにアクセスする必要がある場合、使用されるパッケージマネージャーによって、以下のいずれかの環境変数​を設定してプルーニングステップをスキップできます。

  • NPM_CONFIG_PRODUCTION=false​ (npm​ の場合)
  • YARN_PRODUCTION=false​ (Yarn v1​ の場合)
  • YARN2_SKIP_PRUNING=true​ (Yarn v2+​ の場合)
$ heroku config:set NPM_CONFIG_PRODUCTION=false YARN_PRODUCTION=false YARN2_SKIP_PRUNING=true

NODE_ENV は production ではない

デフォルトでは、NODE_ENV​ は production​ に設定されています。NODE_ENV​ が 他の値である場合、プルーニングステップはスキップされます。

$ git push heroku main
...
-----> Pruning devDependencies
       Skipping because NODE_ENV is 'test'
...

Yarn を使用するために生成された他のファイルと一緒に、作成されたすべての成果物を .yarn​ ファイルで git にチェックインします。

ビルドプロセスのカスタマイズ

デプロイ中に実行するビルドステップがアプリにある場合、package.json 内で build​ スクリプトを使用できます。

"scripts": {
  "start": "node index.js",
  "build": "webpack"
}

Package.json 内に、Heroku 用にカスタマイズする必要がある build​ スクリプトがすでに存在する場合、heroku-postbuild​ スクリプトを定義し、build​ スクリプトの代わりに実行できます。

"scripts": {
  "start": "node index.js",
  "build": "ng build",
  "heroku-postbuild": "ng build --prod" // this will be run on Heroku
}

heroku-postbuild​ スクリプトが指定された場合、build​ スクリプトは実行されません​。

Heroku 固有のビルドステップ

npm install​ および yarn install​ に標準的な preinstall​ および postinstall​ スクリプトがある場合、Heroku の他のビルドステップの前後に限りスクリプトを実行できます。たとえば、Heroku が依存関係をインストールする前に、npm、git、または ssh の設定が必要な場合もあります。または、依存関係がインストールされた後に、本番アセットのビルドが必要な場合もあります。

Heroku 固有のアクションの場合、heroku-prebuild​、heroku-postbuild​、および heroku-cleanup​ スクリプトを使用します。

"scripts": {
  "heroku-prebuild": "echo This runs before Heroku installs dependencies.",
  "heroku-postbuild": "echo This runs after Heroku installs dependencies, but before Heroku prunes and caches dependencies.",
  "heroku-cleanup": "echo This runs after Heroku prunes and caches dependencies."
}

環境変数

アプリの 環境はビルド中に使用可能で、環境変数の値に基づいてビルド動作を調整できます。たとえば次のようになります。

$ heroku config:set MY_CUSTOM_VALUE=foobar

ビルドフラグ

アプリがビルドステップを実行中の場合、開発および本番用に使用されるようにしてください。そうでない場合、ビルドフラグ環境変数を使用して、ビルドスクリプトのフラグを設定します。たとえば、ビルドステップが以下であるとします。

"scripts": {
  "build": "ng build"
}

NODE_BUILD_FLAGS​ 環境変数を設定できます。

$ heroku config:set NODE_BUILD_FLAGS="--prod"

この変数を設定すると、ビルドステップでは ng build --prod​ を代わりに実行します。

npm の設定

npm​ は、NPM_CONFIG​ で始まるあらゆる環境変数から設定を読み取ります。

また、プロジェクトのルートの .npmrc​ ファイル経由で npm の動作を制御することもできます。

NPM_CONFIG_PRODUCTION​ が true の場合、npm は NODE_ENV​ が ‘production’ であるサブシェル内のすべてのスクリプトを自動実行します。

プライベート依存関係

NPM Enterprise や Gemfury などのプライベート依存関係ソースからプルする場合、プロジェクトはアクセストークンを使用して代替レジストリを設定する必要があります。

プライベートレジストリ URL を .npmrc​ に追加します。この場合は、npm のレジストリがパブリックであっても、これを指定します。スコープは、レジストリのプライベートモジュール用に使用されるスコープと置換する必要があります。次に、認証トークンを使用して、指定されるレジストリ URL を追加します。

echo "@scope:registry=https://registry.npmjs.org" >> .npmrc
echo -e "//registry.npmjs.org/:_authToken=\${NPM_TOKEN}" >> .npmrc

このレジストリ URL は npm レジストリに固有のものですが、他のプライベートパッケージレジストリが類似の URL を持つ場合もあります。プライベートレジストリのドキュメントを確認してください。

.npmrc​ は以下のようになります。

@scope:registry=https://registry.npmjs.org
//registry.npmjs.org/:_authToken=${NPM_TOKEN}

NPM_TOKEN​ が Heroku 設定に追加されたことで、ビルドによってトークンにアクセスでき、プライベートパッケージをインストールできます。

heroku config:set NPM_TOKEN=PRIVATE_NPM_TOKEN

バイナリダウンロードのカスタマイズ

環境変数​ NODE_BINARY_URL​ および YARN_BINARY_URL​ をカスタム URL に設定することで、Node と yarn のバイナリのダウンロード先をカスタマイズできます。次に例を示します。

$ heroku config:set NODE_BINARY_URL=https://s3.amazonaws.com/your-custom-binary-url/

キャッシュの動作

Heroku には、ビルド間で永続するビルドキャッシュ​があります。このキャッシュは、npm、Yarn および bower からのキャッシュを保存するために使用されます。

必要に応じて、Node.js アプリのすべてのキャッシュを無効化できます。

$ heroku config:set NODE_MODULES_CACHE=false
$ git commit -am 'disable node_modules cache' --allow-empty
$ git push heroku main

カスタムキャッシュ

Heroku はデフォルトで、node_modules​ および bower_components​ ディレクトリを保存します。トップレベルの package.json に cacheDirectories​ 配列を指定することで、これらのデフォルトをオーバーライドできます。

たとえば、クライアントおよびサーバーのサブディレクトリ内でビルドする場合は、次のようになります。

"cacheDirectories": ["client/node_modules", "server/node_modules"]

また、アプリで何らかの種類の大きいディレクトリが必要で、data/dictionary.txt に保管される場合は、次のようになります。

"cacheDirectories": ["data"]

ランタイムの動作

buildpack では、node​、npm​、および node_modules/.bin​ を PATH​ に指定するため、heroku run​ で実行したり、Procfile 内で直接使用したりできます。

$ cat Procfile
web: npm start

NODE_ENV​ 環境変数はデフォルトで ‘production’ に設定されますが、任意の文字列に設定できます。

$ heroku config:set NODE_ENV=staging

通常の場合、NODE_ENV​ は ‘production’ です。いくつかのモジュール (express を含む) では、NODE_ENV​に基づいてそれらの動作を暗黙的に変更します​。

デフォルトの Web プロセスタイプ

最初に、Heroku はプロセスタイプを指定する Procfile​ を検索します。

ビルドプロセス中にアプリのルートディレクトリに Procfile​ が存在しない場合、package.json 内で指定できるスクリプトである npm start​ を実行することによって Web プロセスが開始されます。

"scripts": {
  "start": "node server.js"
}

アプリの構成で web​ 以外のプロセスのみを実行する場合、web​ を明示的にスケールダウンし、他のプロセスタイプをスケールアップする必要があります。たとえば、次のようになります。

$ heroku scale web=0 worker=1

警告

ビルドに失敗した場合、Node.js buildpack は Node アプリケーション内の一般的な問題を特定し、警告と共にベストプラクティスとなる推奨事項を提供します。Node.js のビルドの問題がある場合、この場所からデバッグを開始することをお勧めします。

また、Node.js の一般的な問題のトラブルシューティング​に役立つドキュメントもあります。

アドオン

デフォルトでプロビジョニングされるアドオンはありません。 アプリ用のデータベースが必要な場合は、明示的に追加してください。

$ heroku addons:create heroku-postgresql

複数の buildpack による動作

Node.js buildpack を他の buildpack​ と一緒に使用するとき、後続の buildpack が使用するために、node​、npm​、および node_modules​ バイナリを PATH​ に自動的にエクスポートします。

理解を深める

Heroku Node.js buildpack はオープンソースです。buildpack の動作方法を技術的にさらに理解するには、github.com/heroku/heroku-buildpack-nodejs​ のソースコードを調べてください。

関連カテゴリー

  • Node.js
Yarn 2 への移行 Heroku での Node.js アプリのデプロイ

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences