nextjs with typescript:34 RuntimeConfig設定、.envファイル

【１】サーバサイド、クライアントサイドRuntimeConfig

Next.jsアプリ上の環境変数(RuntimeConfig)を以下２つに分けて設定がすることができる。

・serverRuntimeConfig
　⇒　サーバサイド側の処理でのみに使える環境変数相当
・publicRuntimeConfig
　⇒　クライアント側とサーバサイド側の両方で使用できる環境変数相当

■例
【./package.json】※今回は確認用にcross-envで環境変数埋め込み

{
...(略)...

 "scripts": {
   "dev": "cross-env MY_ENV=1234 MY_SECRET=secret next",
               ...(略)...
 },

...(略)...
}

【./next.config.js】

module.exports = {
   env:{
       MY_ENV:process.env.MY_ENV,
       GREETING:process.env.GREETING
   },
   serverRuntimeConfig:{
       //サーバサイド側でのみ利用可能
       MY_SECRET:process.env.MY_SECRET
   },
   publicRuntimeConfig:{
       //クライアント、サーバサイド側両方で利用可能
       MY_MESSAGE:"welcome!"
   }
}

■環境変数(RuntimeConfig)へのアクセスの仕方

import getConfig from 'next/config';

...(略)...
const { serverRuntimeConfig, publicRuntimeConfig } = getConfig();

...(略)...
console.log(serverRuntimeConfig.MY_SECRET);
console.log(publicRuntimeConfig.MY_MESSAGE);

・サンプル画面で動作確認
【./pages/envdemo2.tsx】※型定義などは細かなところは省略

import { GetServerSideProps } from "next"
import getConfig from 'next/config';


const { serverRuntimeConfig, publicRuntimeConfig } = getConfig();


// サーバ、クライアント両方
console.log(publicRuntimeConfig.MY_MESSAGE);
//サーバサイド側のみ
console.log(serverRuntimeConfig.MY_SECRET);


const EnvDemo2 =(props:any) =>{
   return (
       <div>
           <div>
           MY_MESSAGE:{publicRuntimeConfig.MY_MESSAGE}
           </div>
           <div>
           MY_SECRET:{serverRuntimeConfig.MY_SECRET}
           </div>
           {JSON.stringify(props,null,4)}
       </div>
   );
}

export default EnvDemo2


export const getServerSideProps:GetServerSideProps = (ctx) =>{
   return {
       props:{
           MY_MESSAGE:publicRuntimeConfig.MY_MESSAGE,
           MY_SECRET:serverRuntimeConfig.MY_SECRET
       }
   };
}

【２】「.envファイル」

Next.jsでは「.env.local」の他にもいくつか環境変数ファイルを認識してくれる。

・.env　⇒　どの環境でもロードされる。
・.env.development　⇒「next dev (yarn dev)」時に読み込まれる。
・.env.production　⇒　「next build (yarn build)」や「next start (yarn start)」時に読み込まれる。

環境変数ファイルが複数ある場合、どれか一つロードということではなく、実行環境に合致する環境変数は全部ロードする挙動となる。（※例えば ローカル環境で「yarn dev」すると「.env.local」「.env.development」、「.env」の３つがロードされる、等）

　アプリ起動時に出力されるイベントログで、どの環境変数ファイルをロードしているのかも確認しよう。

【３】githubなどでソースコードを共有する際

　github等でコードを共有する場合は、見えてはいけない環境変数までアップロードしてしまわないように注意が必要となる。github上でみかける以下のような対応をしよう。

■例：.envファイルなどにAPIのKEYを配置しているような場合

（１）「.env.sample」ファイルを作成して、以下のような記述をいれておく【.env.sample】

API_KEY=WRITE_YOUR_API_KEY_HERE

（２）このようなファイルを作成しつつ、ReadMe等わかるところに「.env.sample⇒.envにリネームして使う旨」を記述をいれておく。

（３）「.gitignore」に「.envファイル」は除外する設定を入れる
【.gitignore】

.env
node_modules/
mydatabase.db

▲このファイルでは「.envファイル」、「node_modules/（ディレクトリ配下）」、「mydatabase.db」がgit処理から除外される。

つまり、github上には.envファイルはあげずに、代わりに.env.sampleをあげておいて、利用するユーザに適宜リネームや修正をしてもらう、ということ。
　なお、vercelやgcp(Google Cloud Platform)などホスティングサービス上にソースを上げるときには、環境変数をどう扱うのかは各サービスで確認しよう。