フィーチャーフラグ

Gutenberg プロジェクトでは、しばしば、書いたコードが WordPress コアとしてリリースされるのか、それとも、特定の実験的な機能がプラグインでのみ有効なのかを制御する必要があります。

多くの場合、このような要求は「フィーチャーフラグ」を使用して処理されます。

process.env.IS_GUTENBERG_PLUGIN の導入

process.env.IS_GUTENBERG_PLUGIN は、現在プラグイン内でコードが実行されているかどうかを表す環境変数です。プラグイン用にコードベースがビルドされると、この変数は true に設定されます。コア用にビルドする場合は、false または undefined に設定されます。

Top ↑

基本的な使用方法

プラグイン専用の関数や定数は、次の三項構文を使用してエクスポートしてください。

function myPluginOnlyFeature() {
	// implementation
}

exportconst pluginOnlyFeature =
	process.env.IS_GUTENBERG_PLUGIN ? myPluginOnlyFeature : undefined;

非プラグイン環境では、process.env.IS_GUTENBERG_PLUGIN のエクスポートは undefined になります。

プラグインのみの機能をインポートし、呼び出す場合はエラーを避けるため、関数呼び出しを if 文で囲んでください。

import { pluginOnlyFeature } from'@wordpress/foo';

if ( process.env.IS_GUTENBERG_PLUGIN ) {
	pluginOnlyFeature();
}

Top ↑

動作原理

webpack のビルド時、すべての process.env.IS_GUTENBERG_PLUGIN は webpack の define プラグイン を使用して置き換えられます。

次のようなコードがある場合

if ( process.env.IS_GUTENBERG_PLUGIN ) {
	pluginOnlyFeature();
}

コードベースをプラグインとしてビルドすると、変数はブール値 true で置き換えられます。

if ( true ) {
	pluginOnlyFeature();
}

if 文の本体内にあるコードは、この true のため、実行されます。

コアでは、process.env.IS_GUTENBERG_PLUGIN 変数は undefined で置換されるため、ビルドされたコードは以下のようになります。

if ( undefined ) {
	pluginOnlyFeature();
}

undefined は false と評価されるため、プラグインのみの機能はコア内部では実行されません。

Top ↑

呼ばれないコードの削除

本番リリース用にコードをビルドする場合、webpack はコードをミニファイ (縮小化) し、可能な限り不要な JavaScript のコードを削除しようとします。その中の1つが「呼ばれないコードの削除」です。

次のコードに出会うと webpack は周りの if 文は不要と判断します。

if ( true ) {
	pluginOnlyFeature();
}

条件は常に true と評価されるため、if 文を削除し、中の実行部分のみを残すことができます。

pluginOnlyFeature();

同様にコアのビルドの場合、次の if 文の条件は常に false と解決されます。

if ( undefined ) {
	pluginOnlyFeature();
}

ミニファイプロセスは内容を含む if 文全体を削除します。これでプラグインのみのコードは、コア用にビルドされた JavaScript に含まれません。

Top ↑

なぜ IS_GUTENBERG_PLUGIN 関連の評価結果を変数に割り当てるべきではないのですか ? たとえば const isMyFeatureActive = process.env.IS_GUTENBERG_PLUGIN === true ではいけないのですか ?

webpack のミニファイが呼ばれないコードを削除できるよう、コードに複雑性を持ち込まないようにするためです。詳細については上の「呼ばれないコードの削除」セクションを参照してください。

原文

最終更新日: 2022年2月20日