Editor styles are not enqueued properly

[groenroos]

Following on from #107, I'm trying to make sure the editor-style.scss asset in Vite is enqueued properly - since editor styles need to be added with the add_editor_style() function instead of wp_enqueue_style().

Currently, even when modifying the filter I wrote in #107, the editor-style.{hash}.css asset will be enqueued as a normal style, and thus the CSS is incorrectly applied to the entire page (instead of just the editor viewport). It also won't be enqueued in any way whatsoever for any Classic / TinyMCE-based editors (e.g. the ACF WYSIWYG field), since those operate on an iframe.

function my_add_editor_style($assets, $manifest, $entry, $options) {
	$url = Vite\prepare_asset_url( $manifest->dir );
	$item = $manifest->data->{$entry};

	/* Editor style */
	if (str_contains($item->file, 'editor-style')) {
		add_action('admin_init', function() {
			add_editor_style($item->file);
		});
	}

	/* ... */

	return $assets;
}
add_filter( 'vite_for_wp__production_assets', 'my_add_editor_style', 10, 4 );

The above doesn't work. The typical approach is to hook to admin_init, but perhaps admin_init has already been processed before we get to this filter?

The situation is additionally complicated by the facts that:

• add_editor_style() expects the asset path parameter to be relative to the theme folder, not the WP root. This is also not necessarily the same as the Vite root, either.
• Gutenberg will want to dynamically inline and transform the built CSS, which won't work in dev mode when relying on Vite to transform SCSS on-demand (and thus the CSS asset is in fact JS)

Ideally, this plugin would handle editor styles appropriately out of the box; either by sniffing the filename and/or allowing the user to define the entry point(s) they want to use for editor styles.

In the interim, I'd welcome any ideas for a way forward! 🙏