@wordpress/env

wp-env を使用してプラグインやテーマのビルド用とテスト用の WordPress ローカル環境を簡単にセットアップできます。簡単にインストールできて構成する必要もありません。

Docker が動作していることを確認し、以下のコマンドを実行してください。

$ cd /path/to/a/wordpress/plugin
$ npm -g i @wordpress/env
$ wp-env start

http://localhost:8888 (ユーザー名: admin、パスワード: password) でローカル環境が利用できます。

データベースの認証情報は、ユーザー root、パスワード password です。データベースに直接接続するための完全なガイドは「Accessing the MySQL Database」を参照してください。

wp-env は以下の一般に使用される開発ツールを必要とします。

• Docker: wp-env は Docker を利用します。OS ごとの Docker のインストール手順を参照してください。Windows (WSL2 バックエンドを推奨)、macOS、Linux。
• Node.js: wp-env は Node スクリプトとして書かれています。最新の LTS バージョンのインストールには nvm のような Node バージョンマネージャを使用してください。代替として、ここから直接ダウンロードもできます。
• git: Git は、WordPress、プラグイン、テーマなどのソース管理からのソフトウエアのダウンロードに使用されます。ここにインストール手順があります。

前提ソフトウエアのインストールを確認できたら、グローバルに wp-env をインストールできます。

$ npm -g i @wordpress/env

これで wp-env を使うことができます !

プロジェクトにすでに package.json がある場合、wp-env をローカルパッケージとして使用することもできます。まず wp-env を開発依存としてローカルにインストールします。

$ npm i @wordpress/env --save-dev

グローバルに wp-env をインストールしている場合、これを実行すると、自動的にローカルのプロジェクトレベルのパッケージが実行されます。代替として wp-env を、npx で実行できます。npx は npm とともに自動的にインストールされるユーティリティです。npx は node モジュールを通してインストールされた wp-env などのバイナリを見つけます。例: npx wp-env start --update。

グローバルインストールや npx を使いたくなければ、package.json を変更し、npm scripts (https://docs.npmjs.com/misc/scripts) にコマンドを追加してください。

"scripts": {
	"wp-env": "wp-env"
}

この方法で wp-env をインストールした場合、この文書で説明するすべての wp-env コマンドの前に npm run を追加してください。たとえば

# npm に対してではなく、スクリプト (wp-env) にフラグを渡すには、別の二重ダッシュ(--)を追加する必要があります。
$ npm run wp-env start -- --update

と実行します。以後は次のような形式のみ記述します。

$ wp-env start --update

まず Docker が実行されていることを確認してください。確認するにはシステムトレイ、またはメニューバーの Docker アイコンをクリックします。

次に WordPress プラグインやテーマを含むディレクトリーに移動してください。

$ cd ~/gutenberg

ローカル環境を開始します。

$ wp-env start

Web ブラウザで http://localhost:8888 を開きます。ローカルのプラグインやテーマがインストール、有効化された状態で WordPress が表示されます。デフォルトのログインアカウントはユーザー名 admin、パスワード password です。

ローカル環境を停止するには以下を実行します。

$ wp-env stop

以下のトラブルシューティングを順に実行することで、多くの一般的な問題を解決できます。

まず wp-env が動作していることを確認します。現在実行中の Docker コンテナ一覧を出力します。

$ docker ps

リストにはデフォルトで3つのエントリーが表示されます。ポート 8888 の wordpress、ポート 8889 の tests-wordpress、ポート 3306 の mariadb です。

デフォルトでは wp-env はポート 8888 を使用し、ローカル環境が http://localhost:8888 で利用可能になります。

別のサーバーと衝突しないように wp-env の使用するポートを構成できます。wp-env を開始する際に WP_ENV_PORT 環境変数を指定してください。

$ WP_ENV_PORT=3333 wp-env start

docker ps を実行し PORTS 列を参照すると、現在 wp-env がどのポートを使用しているかを調べることができます。

.wp-env.json ファイル内にポート番号を指定することもできますが、環境変数が指定されるとそちらが優先されます。

wp-env を再起動すると、内部で使用される Docker コンテナが再起動され、多くの問題を解消します。

wp-env を再起動するには、wp-env start を再実行するだけです。自動的にコンテナを停止し、起動します。引数に --update を渡すと、更新をダウンロードし、WordPress を再設定します。

$ wp-env start --update

Docker を再起動すると、内部で使用する Docker コンテナとボリュームが再起動され、多くの問題を解消します。

Docker を再起動するには

1. システムトレイ、または、メニューバーの Docker アイコンをクリックする。
2. Restart を選択する。

Docker の再起動後、wp-env を起動します。

$ wp-env start

ローカル環境の使用するデータベースをリセットすると、多くの問題、特に WordPress のインストールに関する問題が解消します。

データベースをリセットするには

⚠️ 警告: 次のコマンドは、ローカル WordPress 環境内の投稿、ページ、メディア等を完全に削除します。

$ wp-env clean all
$ wp-env start

上のすべてがうまくいかない場合、wp-env destroy を使用してローカルの Docker コンテナ、ボリューム、ファイルを強制的に削除できます。ゼロからやり直すことができます。

すべてを破壊するには

⚠️ 警告: 次のコマンドは、ローカル WordPress 環境内の投稿、ページ、メディア等を完全に削除します。

$ wp-env destroy
# この新しいインスタンスは、既存データのないクリーンなものです。
$ wp-env start

wp-env にはデフォルトで、インストールされる WordPress のバージョンに対応した WordPress の PHPUnit テストファイル が含まれます。環境変数 WP_TESTS_DIR は、各コンテナ内のこれらのファイルの場所を指定します。これらのファイルが環境に含まれるため、パッケージを使用したり、自分でインストールしてマウントしたりする必要はありません。これらのファイルを使用したくない場合は、環境変数 WP_TESTS_DIR を無視して、好きな場所から読み込めます。

環境内にはデフォルトで wp-tests-config.php ファイルがありますが、独自のファイルを使いたい場合もあります。WordPress の WP_TESTS_CONFIG_FILE_PATH 定数を使用すると、テストで使用する wp-config.php ファイルを変更できます。これを bootstrap.php ファイル内の任意のパスに設定すると、環境に含まれるファイルの代わりに選択したファイルを使用できます。

環境内では利便性のため Composer、PHPUnit、wp-cli を利用できます。これらの実行ファイルを実行するには、wp-env run <env> <tool> <command> を使用してください。例えば、wp-env run cli composer install、wp-env run tests-cli phpunit などです。また、wp-env run cli bash や wp-env run cli wp shell のように様々なシェルにアクセスできます。

env では、cli と wordpress はデータベースとマップされたボリュームを共有しますが、cli 環境ではより多くのツールを使用できます。別個のテスト用データベースには tests-cli または tests-wordpress 環境を使用する必要があります。

デフォルトでは、run コマンドの cwd (ワークディレクトリ) は、WordPress のインストールルートです。プラグインで作業している場合、composer や phpunit コマンドが、作業中のプラグインに関連して実行するよう、--env-cwd を渡す必要があります。例えば、wp-env run cli --env-cwd=wp-content/plugins/gutenberg composer install です。

これを簡単に実行するには、package.json ファイルにスクリプトを追加します。

{
	"scripts": {
		"composer": "wp-env run cli --env-cwd=wp-content/plugins/gutenberg composer"
	}
}

npm run composer install を実行すると、その環境で composer install が実行されます。これは phpunit や wp-cli などでも同様です。

wp-env 環境には Xdebug がインストールされていますが、デフォルトではオフになっています。Xdebug を有効にするには wp-env start コマンドの --xdebug フラグを使用します。以下ではフラグの動作について説明します。

# Xdebug モードを "debug" に設定 (ステップデバッグ用)
wp-env start --xdebug

# Xdebug モードを "off" に設定
wp-env start

# リストしたそれぞれの Xdebug モードを有効
wp-env start --xdebug=profile,trace,debug

npm run を使って wp-env を実行する場合、たとえば、Gutenberg リポジトリで作業する場合や、wp-env にプロジェクトのローカルな依存関係がある場合、--xdebug コマンドの前に、忘れずに二重ダッシュを追加してください。

npm run wp-env start -- --xdebug
# Alternatively, use npx:
npx wp-env start --xdebug

これを忘れると、wp-env start コマンドの代わりに --xdebug パラメータが npm に渡され、無視されます。

Xdebgu のモードと定義については Xdebug ドキュメント を参照してください。

Xdebug 3 のみをインストールするため、Xdebug としては PHP 7.2 (デフォルト) 以上が必要です。phpVersion に古いバージョンに設定されている場合、Xdebug はインストールできません。

IDE から Xdebug に接続するには以下の IDE 設定を使用できます。この JSON は VS Code の launch.json 形式 (詳細についてはこちら) と PHP デバッグエクステンション でテストされました。なお、パスマッピングは特定のプラグインを指しています。これを wp-env インスタンス内の作業中のソースコードを指すよう更新してください。

port と pathMappings のみを IDE で使用する形式に変換する必要があります。

{
	"name": "Listen for XDebug",
	"type": "php",
	"request": "launch",
	"port": 9003,
	"pathMappings": {
		"/var/www/html/wp-content/plugins/gutenberg": "${workspaceFolder}/"
	}
}

リポジトリに .vscode/launch.json ファイルを作成したら、それを グローバル gitignore ファイル に追加すると良いでしょう。ファイルはプライベートになり、リポジトリにはコミットされません。

IDE Xdebug 設定が有効になればあとはデバッガを起動し、PHP コードの任意の行にブレークポイントを置き、ブラウザをリフレッシュするだけです。

まとめ:

1. Xdebug を有効化して wp-env を起動する: wp-env start --xdebug
2. もしまだなら IDE 用に適切な Xdebug エクステンションをインストールする。
3. IDE デバッガーがポート 9003 と wp-env 内の正しいソースファイルを使用するよう構成する。
4. デバッガーを起動し、PHP コードの任意の行にブレークポイントを置く。
5. wp-env の稼働する URL をリフレッシュすれば、ブレークポイントに達する。

wp-env は生成したファイルを wp-env ホームディレクトリ、デフォルトでは ~/.wp-env に置きます。例外は Linux で、Snap パッケージの互換性のため、ファイルは ~/wp-env に置かれます。wp-env ホームディレクトリには各プロジェクトのサブディレクトリが /$md5_of_project_path として作成されます。wp-env ホームディレクトリを変更するには、WP_ENV_HOME 環境変数を設定してください。例えば WP_ENV_HOME="something" wp-env start と実行すると、プロジェクトファイルは現行ディレクトリからの相対パスでディレクトリ ./something/$md5_of_project_path にダウンロードされます。

start コマンドは WordPress 環境をインストールし、初期化します。これには指定された任意のリモートのソースのダウンロードも含まれます。wp-env はデフォルトでは構成ファイルが変更されない限り、環境を更新も再構成もしません。ソースを更新し、構成オプションを再度適用するには wp-env start --update を使用してください。既存のコンテンツは上書きされません。

wp-env start

WordPress 開発環境をポート 8888 (​http://localhost:8888​) で (ポートは WP_ENV_PORT で指定可)、
テスト環境を 8889 (​http://localhost:8889​) で (ポートは WP_ENV_TESTS_PORT で指定可) 開始します。
コマンドは WordPress インストールディレクトリ、プラグインやテーマのディレクトリ、
または .wp-env.json ファイルのあるディレクトリで実行する必要があります。最初のインストール後、
'--update' フラグを使用して更新をマップされたソースにダウンロードし、WordPress 構成オプションに
再適用します。

オプション:
  --debug    デバッグ出力の有効化                         [boolean] [デフォルト: false]
  --update   ソースの更新をダウンロードし、WordPress 構成に適用する
                                                      [boolean] [デフォルト: false]
  --xdebug   Xdebug を有効化する。指定しなければ Xdebug はオフ。モードがセットされていなければ、
             "debug" を使用する。複数の Xdebug モードを設定でき、コンマで区切る。
			 `--xdebug=develop,coverage`. Xdebug モードの情報については、
             https://xdebug.org/docs/all_settings#mode 参照        [string]
  --scripts  構成済みのライフサイクルスクリプトを実行        [boolean] [デフォルト: true]

wp-env stop

実行中の WordPress 開発環境、テスト環境を停止し、ポートを解放します。

オプション:
  --debug    デバッグ出力の有効化                         [boolean] [デフォルト: false]

wp-env clean [environment]

WordPress データベースをクリアします。

引数:
  environment  どの環境のデータベースをクリアするか。
            [string] [選択: "all", "development", "tests"] [デフォルト: "tests"]

オプション:
  --debug    デバッグ出力の有効化                         [boolean] [デフォルト: false]
  --scripts  構成済みのライフサイクルスクリプトを実行        [boolean] [デフォルト: true]

run コマンドを使用して、シェルセッションを開いたり、WP-CLI コマンドを呼び出したり、コンテナ内で任意の代替コマンドを実行できます。

いくつかのケースでは、wp-env run は、コンテナに渡すオプションと競合します。 このとき wp-env は自身のオプションとして扱い、応じた処理を行います。 例えば、wp-env run cli php --help を実行すると、 wp-env run のヘルプが表示されます。

こレを回避するには、競合するオプションをダッシュ2つ (--) の後に渡します。wp-env は、ダッシュ2つ以降を処理せず、単純にコンテナに渡します。例えば、PHP のヘルプを表示するには、wp-env run cli php -- --help を使用します。

wp-env run <container> [command...]

動作している Docker コンテナ内で任意のコマンドを実行します。ダッシュ2つ (`--`) を使用すると、
引数をパースせずにコンテナに渡します。これは、以下で定義されるオプションを使用する際に必要です。
シェルセッションを開くには `bash` を使用します。`composer` と `phpunit` の両方は、
すべての WordPress と CLI コンテナで利用可能です。WP-CLI も CLI コンテナで利用可能です。

引数:
  container  コマンドを実行する Docker サービス                     [string] [必須]
             [選択: "mysql", "tests-mysql", "wordpress",
                   "tests-wordpress", "cli", "tests-cli", "composer", "phpunit"]
  command    実行するコマンド                                      [必須]

オプション:
  --debug    デバッグ出力の有効化                     [boolean] [デフォルト: false]
  --env-cwd  コマンドのコンテナ内でのワークディレクトリ。先頭にスラッシュのないパスは、
             WordPress のルートからの相対パス         [string] [デフォルト: "."]

例:

wp-env run cli wp user list
⠏ Running `wp user list` in 'cli'.

ID      user_login      display_name    user_email      user_registered roles
1       admin   admin   wordpress@example.com   2020-03-05 10:45:14     administrator

✔ Ran `wp user list` in 'cli'. (in 2s 374ms)

wp-env run tests-cli "wp post create --post_type=page --post_title='Ready'"

ℹ Starting 'wp post create --post_type=page --post_title='Ready'' on the tests-cli container.

Success: Created post 5.
✔ Ran `wp post create --post_type=page --post_title='Ready'` in 'tests-cli'. (in 3s 293ms)

wp-env run tests-cli wp shell
ℹ Starting 'wp shell' on the tests-cli container. Exit the WordPress shell with ctrl-c.

Starting 31911d623e75f345e9ed328b9f48cff6_mysql_1 ... done
Starting 31911d623e75f345e9ed328b9f48cff6_tests-wordpress_1 ... done
wp> echo( 'hello world!' );
hello world!
wp> ^C
✔ Ran `wp shell` in 'tests-cli'. (in 16s 400ms)

wp-env run cli wp plugin install custom-post-type-ui

Creating 500cd328b649d63e882d5c4695871d04_cli_run ... done
Installing Custom Post Type UI (1.9.2)
Downloading installation package from https://downloads.wordpress.org/plugin/custom-post-type-ui.zip...
The authenticity of custom-post-type-ui.zip could not be verified as no signature was found.
Unpacking the package...
Installing the plugin...
Plugin installed successfully.
Success: Installed 1 of 1 plugins.
✔ Ran `plugin install custom-post-type-ui` in 'cli'. (in 6s 483ms)

wp-env 環境で REST API (wp-env/wp/v2/) のエンドポイントにアクセスするには、この操作を行います。プレーンなパーマリンクでは、エンドポイントは利用できません。

例

パーマリンクを投稿名だけに設定する

wp-env run cli "wp rewrite structure /%postname%/"

パーマリンクを年、月、投稿名に設定する

wp-env run cli "wp rewrite structure /%year%/%monthnum%/%postname%/"

wp-env destroy

WordPress 環境を破壊します。WordPress 環境と関連する Docker コンテナ、ボリューム、
ネットワークを削除し、ローカルファイルを削除します。

オプション:
  --debug    デバッグ出力の有効化                         [boolean] [デフォルト: false]
  --scripts  構成済みのライフサイクルスクリプトを実行        [boolean] [デフォルト: true]

wp-env logs [environment]

指定した WordPress 環境の PHP と Docker のログを表示します。

引数:
  environment  どの環境のログを出力するか
      [string] [選択: "development", "tests", "all"] [デフォルト: "development"]

オプション:
  --debug    デバッグ出力の有効化         [boolean] [デフォルト: false]
  --watch    ログをウオッチする          [boolean] [デフォルト: true]

すべての環境ファイルが格納されているパスを取得します。これには、Docker ファイル、WordPress、PHPUnit ファイル、ダウンロードしたソースが含まれます。

例:

$ wp-env install-path

/home/user/.wp-env/63263e6506becb7b8613b02d42280a49

WordPress のインストールや開発環境で使用するプラグインやテーマをカスタマイズできます。.wp-env.json ファイルに指定し、同じディレクトリーで wp-env を実行してください。

.wp-env.json はテストと開発の両方のインスタンスに適用可能なオプションとしてフィールドをサポートします。

注意: ポート番号に関する環境変数 (WP_ENV_PORT と WP_ENV_TESTS_PORT) は .wp-env.json の値に優先します。

core、plugins、themes、mappings フィールドに指定できる文字列のタイプを以下に示します。

リモートのソースは ~/.wp-env 内の一時ディレクトリーにダウンロードされます。

さらにキー env は上の任意のオプションを個々の環境ごとに上書きできます。たとえば次の .wp-env.json ファイルでは

{
	"plugins": [ "." ],
	"config": {
		"KEY_1": true,
		"KEY_2": false
	},
	"env": {
		"development": {
			"themes": [ "./one-theme" ]
		},
		"tests": {
			"config": {
				"KEY_1": false
			},
			"port": 3000,
			"mysqlPort": 13306
		}
	}
}

development インスタンスでは、cwd がプラグインに、one-theme がテーマにマップされ、KEY_1 が true に、KEY_2 が false に設定されます。デフォルトのポートは引き続き 8888 が使用されます。

tests インスタンスでは、cwd がプラグインマップされますがテーマのマップはありません。また KEY_2 は false のままですが、KEY_1 は false で、デフォルトのポートは 3000 で上書きされます。

この強力な機能により環境ごとにオプションを変更できます。

このファイルのフィールド値は、.wp-env.json の値よりも優先されます。このファイルをバージョンコントロールの対象外とすると、常に希望のローカル環境で上書きできて便利です。注意: plugins や themes などのオプションはマージされません。結果として .wp-env.override.json ファイル内で plugins を設定すると、ベースレベルの構成でリストされたすべてのプラグインを上書きします。マージされるキーは config と mappings のみです。すなわちデフォルト値を失うこと無く自身の wp-config 値を設定できます。

development インスタンスでは次の wp-config 値がデフォルトとして定義されます。

WP_DEBUG: true,
SCRIPT_DEBUG: true,
WP_PHP_BINARY: 'php',
WP_TESTS_EMAIL: 'admin@example.org',
WP_TESTS_TITLE: 'Test Blog',
WP_TESTS_DOMAIN: 'localhost',
WP_SITEURL: 'http://localhost',
WP_HOME: 'http://localhost',

tests インスタンスでは同じすべての値が定義されますが、WP_DEBUG と SCRIPT_DEBUG は false に設定されます。

これらは config 設定内に値を設定することで上書きできます。この値を null に設定すると、定数を完全に定義できなくなります。

また URL を参照する値には環境で指定されたポート番号が含まれます。たとえば testsPort: 3000, port: 2000 を設定すると、WP_HOME は tests インスタンスでは http://localhost:3000、development インスタンスでは http://localhost:2000 になります。

.wp-env.json の lifecycleScripts オプションを使用すると、ライフサイクルの特定の時点で実行される任意のコマンドを設定できます。この設定は WP_ENV_LIFECYCLE_SCRIPT_{LIFECYCLE_EVENT} 環境変数を使用して上書きできます。このとき、残りは例えば WP_ENV_LIFECYCLE_SCRIPT_AFTER_START のように、オプション名をすべて大文字の snake_case で指定します。これらは新しい環境でも、既存の環境でも、実行されることに注意してください。ビルドしたコマンドが連続した実行で環境を壊さないようにしてください。

• afterStart: wp-env start が完了し、環境がセットアップされた後で実行されます。
• afterClean: wp-env clean が完了し、環境がクリーンアップされた後で実行されます。
• afterDestroy: wp-env destroy が環境を破壊した後で、実行されます。

この設定はプラグイン開発時に便利です。

{
	"core": null,
	"plugins": [ "." ]
}

この設定はプラグイン開発時に、最新のコアの変更の影響を見る上で便利です。これは、環境変数 WP_ENV_CORE からも設定できます。

{
	"core": "WordPress/WordPress#master",
	"plugins": [ "." ]
}

プラグインと WordPress コアで同時に作業する場合に便利です。

wordpress-develop の build を実行している場合は、core を build ディレクトリに指定します。

{
	"core": "../wordpress-develop/build",
	"plugins": [ "." ]
}

もし、wordpress-develop を dev モード（例: watch コマンド dev や dev ビルド build:dev）で実行している場合は、core を src ディレクトリに指定します。

{
	"core": "../wordpress-develop/src",
	"plugins": [ "." ]
}

インテグレショーンテストで便利です。古いバージョンの WordPress と異なるプラグインの組み合わせで互いに与える影響をテストできます。

{
	"core": "WordPress/WordPress#5.2.0",
	"plugins": [ "WordPress/wp-lazy-loading", "WordPress/classic-editor" ],
	"themes": [ "WordPress/theme-experiments" ]
}

マッピング構成を使用して mu-plugins を追加できます。マッピング構成を使用すると、WordPress インストール内の任意の場所にディレクトリをマウントできます。サブディレクトリにマウントすることも可能です。ただし theme-1 は有効化されないことに注意してください。

{
	"plugins": [ "." ],
	"mappings": {
		"wp-content/mu-plugins": "./path/to/local/mu-plugins",
		"wp-content/themes": "./path/to/local/themes",
		"wp-content/themes/specific-theme": "./path/to/local/theme-1"
	}
}

デフォルトでは plugins キーのすべてのプラグインは有効化されます。この動きを避けるには mappings キーを使用してください。この方法は常には有効化すべきでない、テスト用のプラグインがある場合に便利です。

{
	"plugins": [ "." ],
	"mappings": {
		"wp-content/plugins/my-test-plugin": "./path/to/test/plugin"
	}
}

1つの環境でのみプラグインを有効化し、他の環境では有効化しない場合、env.<envName> を使用して1つの環境でのみオプションを設定できます。ここではテストインスタンスでのみ現行ディレクトリとテストプラグインを有効化しています。他のインスタンスではプラグインは有効化されません。

{
	"plugins": [ "." ],
	"env": {
		"tests": {
			"plugins": [ ".", "path/to/test/plugin" ]
		}
	}
}

wp-env にカスタムポート番号を指定することで、他の wp-env インスタンスとの衝突を避けられます。

{
	"plugins": [ "." ],
	"port": 4013,
	"env": {
		"tests": {
			"port": 4012
		}
	}
}

<<<<<<< HEAD

互換性やテストのため、wp-env では特定の PHP バージョンを使用できます。これは環境変数 WP_ENV_PHP_VERSION からでも設定できます。

{
	"phpVersion": "7.2",
	"plugins": [ "." ]
}

環境設定後にいくつかのアクションを実行する際に便利です。例えば E2E テスト環境のブートストラップなど。

{
	"lifecycleScripts": {
		"afterStart": "node tests/e2e/bin/setup-env.js"
	}
}

PHP の設定は、.htaccess ファイルをマッピングすることで可能です。.htaccess ファイルは、wp-env を実行したディレクトリから、WordPressのルート (/var/www/html) にマップされます。

{
	"mappings": {
		".htaccess": ".htaccess"
	}
}

.htaccess ファイルには、次のような様々な設定を記入できます。

# Note: the default upload value is 1G.
php_value post_max_size 2G
php_value upload_max_filesize 2G
php_value memory_limit 2G

これは、この環境ではアクセスが難しい php.ini に追加したいオプションがある場合に便利です。

これは、Gutenberg プロジェクトの一部である、個別パッケージです。このプロジェクトは、monorepo として構成されています。複数の自己完結型ソフトウェアパッケージで構成されており、それぞれが特定の目的を持ちます。この monorepo のパッケージは npm で公開され、WordPress や他のソフトウェアプロジェクトで利用されています。

このパッケージや Gutenberg 全体へのコントリビュートの詳細については、プロジェクトのメインのコントリビューターガイドを参照ください。

原文

最終更新日: 2024年7月14日