フロントエンド環境変数の管理方法
原文住所:https://lon.im/post/use-envir...
本稿では、環境変数を使用してフロントエンドプロジェクトを管理する際に発生する問題を主に分析し、一般的なツールで解決策を説明します.
環境変数の使用方法
Webpackベースのフロントエンドプロジェクトを構築する場合(またはNodeベースのプロジェクト、本稿ではWebpackプロジェクトを例に)、開発モデルと生産モデルの2つの実行モデルを提供する必要があります.通常、コマンドを実行する前に環境変数
環境変数の使用中に発生する問題
上記のソリューションでは、ほとんどのシーンを適用できますが、環境変数を設定するプラットフォーム間および永続化の問題は解決できません.
クロスプラットフォーム
Windowsコマンドで環境変数の設定がサポートされていないため、プロジェクトにWindowsオペレーティングシステムを使用するメンバーがいる場合、
永続化
規模が大きくなるにつれて、プロジェクトのカスタム環境変数の数はますます多くなる可能性があります.たとえば、導入後の静的リソースにCDNを使用する必要がある場合、プロジェクトの本番モードでは、カスタムwebpackをサポートするpublicPathフィールドを提供する環境変数が必要です.また、例えば、APIサーバをネイティブではなく、仮想マシンまたは別のコンピュータで実行するメンバーもいます.プロジェクト開発モードでは、カスタムAPIサーバのアドレスとポート番号をサポートするために2つの環境変数を提供する必要があります.開発するたびに、
書き換えjsonではstartコマンド(buildコマンド同様)が
本当に使いやすい環境変数管理ツール
環境変数を管理するには多くのツールがあります.次に、一般的なツールdotenv、cross-env、env-cmdのメリットと不足を簡単に分析します.dotenvはプラットフォーム間および永続化の問題を解決することができるが、使用シーンは限られており、nodeプロジェクトのみが適用され、プロジェクトコードと強く結合されており、nodeコードの実行後に手動でトリガ を実行する必要がある.cross-envは、コマンドラインで環境変数をカスタマイズすることをサポートします.大規模プロジェクトにおけるカスタム環境変数の永続化の問題 を解決できないという問題も明らかである.env-cmdはプラットフォーム間および永続化の問題を解決し、デフォルトの環境変数の定義をサポートし、コマンドラインでのカスタム環境変数 をサポートしないことが不足している.
実際,NPM自体も同様にプロジェクト環境変数を設定する機能を提供している.上記カスタムポート番号の要件を例にとると、
そのため、使いやすいフロントエンド環境変数管理ツールには、次の機能が必要です.サポートコマンドライン設定環境変数 クロスプラットフォーム 永続化は、ローカル環境変数を設定するコマンドラインツール を提供することが望ましい.デフォルト環境変数の設定をサポート NPMが提供する環境変数の取得をサポートする( そのため、fuck-envという環境変数管理ツールが誕生し、「環境変数をパロディする」という意味で、以上のすべての機能をサポートしています.
fuck-envのインストールと使用
パッケージが含まれている場合.jsonとmain.jsの2つのファイルのプロジェクトで、ファイルコードは以下の通りです.
package.json
main.js
メンバーがカスタムポート番号をローカルに永続化する場合は、新しいポートを作成できます.Envファイル(このファイルには.gitignoreを追加し、バージョン管理に計上せず、クラス.iniファイルの単純キー値ペアとしてフォーマットする必要があります).
.env
以降は
環境変数が多すぎる場合、packageをすべて配置します.jsonのconfigフィールドも肥大化しています.fuck-envは、configフィールドの下のすべての環境変数をdefaultに移動するだけで、デフォルトの環境変数を統一的に管理することをサポートします.Envファイル(バージョンライブラリに計上)でいいです.
詳細はこちらを参照してください
fuck-envは,ユーザが環境変数を管理する際に遭遇する様々な問題を解決することに力を入れており,将来的にはより人間的な設計が加わる.もし何か考えがあれば、プロジェクトに貴重な提案を歓迎します.
本稿では、環境変数を使用してフロントエンドプロジェクトを管理する際に発生する問題を主に分析し、一般的なツールで解決策を説明します.
環境変数の使用方法
Webpackベースのフロントエンドプロジェクトを構築する場合(またはNodeベースのプロジェクト、本稿ではWebpackプロジェクトを例に)、開発モデルと生産モデルの2つの実行モデルを提供する必要があります.通常、コマンドを実行する前に環境変数
NODE_ENV
をproduction
に設定し、NODE_ENV=production webpack
コマンドを実行した後、JavaScriptコードでprocess.env.NODE_ENV === 'production'
によって生産モードであると判断し、そうでなければ開発モードである.開発モードで開発サーバを起動し、APIの転送を代行したり、本番モードで連結コードを圧縮したりするなど、異なるモードを区別することで、異なる操作を実行できます.フロントエンドエンジニアリングコマンドをよりよく統一するために、開発モードと生産モードを起動するコマンドをそれぞれpackageに加えることができる.jsonファイルのscriptsフィールドでは、後でnpm start
またはnpm run build
を実行するだけでよい.環境変数を定義することによって、プロジェクトで差異操作を実行する必要性がよく解決されます.メンバーカスタム環境変数をサポートする場合は、プログラムで環境変数の値を優先的に使用すればよい.例えば、ポート番号優先使用環境変数のPORT
の値が設定されており、プロジェクトメンバー開発時にPORT=8080 npm start
コマンドを実行すると、ポート番号8080をカスタマイズできます.環境変数の使用中に発生する問題
上記のソリューションでは、ほとんどのシーンを適用できますが、環境変数を設定するプラットフォーム間および永続化の問題は解決できません.
クロスプラットフォーム
Windowsコマンドで環境変数の設定がサポートされていないため、プロジェクトにWindowsオペレーティングシステムを使用するメンバーがいる場合、
npm run build
(NODE_ENV=production webpack
)の実行に失敗します.Windowsではbuildスクリプトの内容に基づいてset NODE_ENV=production webpack
を手動で実行することもできますが、統合フロントエンドエンジニアリングコマンドの意図を破壊し、プラットフォーム間で環境変数を設定するライブラリを導入する必要があります.cross-envを使用する場合はpackageを書き換える.jsonのbuildスクリプトはcross-env NODE_ENV=production webpack
でプラットフォーム間で動作します.永続化
規模が大きくなるにつれて、プロジェクトのカスタム環境変数の数はますます多くなる可能性があります.たとえば、導入後の静的リソースにCDNを使用する必要がある場合、プロジェクトの本番モードでは、カスタムwebpackをサポートするpublicPathフィールドを提供する環境変数が必要です.また、例えば、APIサーバをネイティブではなく、仮想マシンまたは別のコンピュータで実行するメンバーもいます.プロジェクト開発モードでは、カスタムAPIサーバのアドレスとポート番号をサポートするために2つの環境変数を提供する必要があります.開発するたびに、
PORT=8080 API_SERVER=192.168.100.100 API_PORT=9000 npm start
のような長いコマンドを実行しなければならないメンバーもいるかもしれません.そのため、環境変数を永続化できるツールが必要です.例えばdotenvやenv-cmdを使用します.env-cmdを例にとると、1つだけ作成する.env.localファイル(バージョン管理に計上されません)、書き込み:NODE_ENV=development
PORT=8080
API_SERVER=192.168.100.100
API_PORT=9000
書き換えjsonではstartコマンド(buildコマンド同様)が
env-cmd --fallback ./.env.local webpack
であれば、カスタム環境変数が多すぎるたびに手動で入力する煩雑な問題を解決できます.本当に使いやすい環境変数管理ツール
環境変数を管理するには多くのツールがあります.次に、一般的なツールdotenv、cross-env、env-cmdのメリットと不足を簡単に分析します.
実際,NPM自体も同様にプロジェクト環境変数を設定する機能を提供している.上記カスタムポート番号の要件を例にとると、
npm config set project-name:PORT 8080
(project-nameはプロジェクト名)をプロジェクトディレクトリの下で実行し、npm start
を実行した後、コードの中でprocess.env.npm_package_config_PORT
で8080を取得することができる.パッケージをjsonのconfigフィールドは{"PORT": 8000}
に設定され、npm_package_config_PORT
のデフォルト値を指定します.NPMのconfig機能を用いて環境変数を管理する最大の利点は、packageに置くオリジナルサポートである.json configフィールドのデフォルトの環境変数も表示しやすいです.残念なことに、変数名の前には冗長なnpm_package_config_
があります.スクリプトはpackageからなければなりません.jsonのscriptsフィールドで実行する(すなわち、npm run your_script_nameを実行する).また、すべてのプロジェクトでプロファイル(.npmrc、デフォルトはユーザーディレクトリの下)が共有されており、手動で編集したり表示したりするのは不便です.そのため、使いやすいフロントエンド環境変数管理ツールには、次の機能が必要です.
npm_package_*
およびnpm_config_*
)fuck-envのインストールと使用
npm install fuck-env
パッケージが含まれている場合.jsonとmain.jsの2つのファイルのプロジェクトで、ファイルコードは以下の通りです.
package.json
{
"name": "fuck-env-demo",
"config": {
"PORT": 8000,
"APP_NAME": "$npm_package_name"
},
"scripts": {
"start": "fuck-env node main.js"
},
"dependencies": {
"fuck-env": "*"
}
}
main.js
console.log(process.env.PORT) // 8080
console.log(process.env.APP_NAME) // fuck-env-demo
fuck-env PORT=8080 npm start
を実行すると、WindowsでもPOSIX(macOS、Linuxなど)システムでも「8080」と「fuck-env-demo」が出力されます.メンバーがカスタムポート番号をローカルに永続化する場合は、新しいポートを作成できます.Envファイル(このファイルには.gitignoreを追加し、バージョン管理に計上せず、クラス.iniファイルの単純キー値ペアとしてフォーマットする必要があります).
.env
PORT=8080
以降は
npm start
を実行するだけです.さらにfuck-envには、ローカル環境変数を迅速に設定するためのもう一つのコマンドラインツールも用意されています.例えば、メンバーが9000ポートを使用することを望む場合、fuck set PORT 9000
(fuck-envをグローバルにインストールする必要がある)をプロジェクトルートディレクトリの下で実行することができ、この場合、プロジェクトディレクトリの下で実行することができる.Envファイルの内容は「PORT=9000」となり、fuckコマンドを使用すると環境変数が多い場合に便利です.環境変数が多すぎる場合、packageをすべて配置します.jsonのconfigフィールドも肥大化しています.fuck-envは、configフィールドの下のすべての環境変数をdefaultに移動するだけで、デフォルトの環境変数を統一的に管理することをサポートします.Envファイル(バージョンライブラリに計上)でいいです.
詳細はこちらを参照してください
fuck-envは,ユーザが環境変数を管理する際に遭遇する様々な問題を解決することに力を入れており,将来的にはより人間的な設計が加わる.もし何か考えがあれば、プロジェクトに貴重な提案を歓迎します.