Qiita に「APIのトークンをコードに書いている人へ」という記事が上がっていたので、実際APIキーとかをどういう風に読み込むのが良さげなのかなーと考えてみた。
言語依存のコマンドラインツール等を使用する
JavaScript ならnode-env-file
とかdotenv
とか?
使ったことはないのでわかりません。
問題点は、変数を置換するタイプだと、結局ソース直書きの状態になってしまうこと。 サーバサイドオンリーで使うならいいけど、使い分けるくらいならそもそも使わない。
OSにインストールするタイプの管理用ツールを使用する
direnv
とか。
これが一番楽かもしれないが、clone した人がそのツールをインストールしていない場合、わざわざインストールしてもらわないといけないのが難点。
シェルスクリプトをsource
する
.env.sh
のようなシェルスクリプトを用意する。
#!/bin/bash export API_KEY="your api key" export YOUR_ID="your id"
そして実行。
chmod +x .env.sh source .env.sh
これで環境変数に設定されるので、あとはビルドなりサーバの起動なりをやってあげる。
メリットとしては、コマンドラインで実行するものにも設定できる。 例えば開発用サーバとか。
デメリットは、2つのプロジェクトを行き来するときとかには、毎回これを実行してあげなきゃいけないこと。
ちなみに、package.json のprestart
にsource .env.sh
を指定したら、「source
コマンドがない」って怒られた。
解決方法が分かる方がいたら教えてほしい。
設定ファイルを読み込む
鉄板。
const env = (() => { try { return JSON.parse(fs.readFileSync("path/to/.env.json")); } catch { return defaultEnv; } })();
やっぱこれだね。ロ○テのト○ポ。
専用のソースを配置する
動的インポートができる言語のみ。
JavaScript のimport()
を使う前提で説明する。
const env = (async () => { try { return await import("path/to/.env"); } catch { return defaultEnv; } })();
こんな感じで、プログラム中でモジュールとして読み込むところが、「設定ファイルを読み込む」とは違うところ。 比べるとあまりメリットはないかも。
あえて言えば、JSON等では表現できない動的な値も表現できるというところと、(確か動的インポートはなかったと思うが)Java等ではJSON用クラスを用意しなくてもいいというところか。 とはいえ、APIキーとかは固定値だし、JSON用クラスを作る代わりに設定を書くクラスを作る必要があるので、やっぱりメリットはなさそう。
総括
「シェルスクリプトをsource
する」か「設定ファイルを読み込む」が妥当かと。
くれぐれもソース直書きはやめましょう。
いずれにしろ、.env*
を.gitignore
に入れておかないと、不正利用されてとんでもないことになりかねないのでご注意を。
FXで有り金全部溶かした人の顔にはなりたくないですな。