<?php
/**
 * WordPress block-editor asset manifest for `clb/product-card`.
 *
 * Hand-authored counterpart to the manifest `@wordpress/scripts build`
 * would otherwise emit alongside `index.js`. WordPress reads this file
 * automatically when `block.json` declares `"editorScript": "file:./index.js"`
 * (and when `register_block_type_from_metadata()` resolves the script
 * handle): it picks up the `dependencies` array verbatim and forwards
 * it to `wp_register_script()` so the editor bundle waits for
 * `wp-blocks` / `wp-element` / `wp-i18n` to be present before
 * `index.js` runs `wp.blocks.registerBlockType()`.
 *
 * Without this file the script handle gets registered with an empty
 * deps array, the `wp` global is not guaranteed to exist when the
 * script runs, and the block silently fails to register on the editor
 * side -- the plugin's blocks then never appear in the Gutenberg
 * inserter even though the server-side block type is registered and
 * the dynamic `render_callback` works for already-inserted blocks.
 *
 * The `version` slot is left as an empty string so WordPress falls
 * back to the file's mtime (the same behavior `wp-scripts` ships when
 * no version-stamping is configured); a future build pipeline can
 * overwrite this manifest with a content-hash version without
 * changing anything else.
 *
 * Keep in sync with `index.js`: every `wp.<package>` global that
 * `index.js` reads must have a matching `wp-<package>` handle in the
 * `dependencies` array below.
 *
 * @package CommerceLinkBuilder
 */

return array(
	'dependencies' => array(
		'wp-blocks',
		'wp-element',
		'wp-i18n',
		'wp-api-fetch',
		'wp-block-editor',
		'wp-components',
	),
	'version'      => '0.2.2',
);
