Can not deprecate and migrate attributes for a block that use filters

[mkaz]

Background

My code-syntax-block plugin extends the core/code block adding a language attribute that the user can set, it uses this with the Prismjs library to add color syntax on the front-end.

The markup I used looks lile: <code lang="javascript"> // foo </code>

This turns out to be an accessibility issue since the lang property should only be valid spoken languages MDN Spec

Goal: I want to migrate the lang attribute to data-lang

Issue

I have a PR here that switches it and adds a deprecated property, however it does not work due to the following:

In blocks/src/api/registration.js

gutenberg/packages/blocks/src/api/registration.js

Lines 291 to 314 in e0de351

	const preFilterSettings = { ...settings };
	settings = applyFilters( 'blocks.registerBlockType', settings, name );
	if ( settings.deprecated ) {
	settings.deprecated = settings.deprecated.map( ( deprecation ) =>
	pick(
	// Only keep valid deprecation keys.
	applyFilters(
	'blocks.registerBlockType',
	// Merge deprecation keys with pre-filter settings
	// so that filters that depend on specific keys being
	// present don't fail.
	{
	// Omit deprecation keys here so that deprecations
	// can opt out of specific keys like "supports".
	...omit( preFilterSettings, DEPRECATED_ENTRY_KEYS ),
	...deprecation,
	},
	name
	),
	DEPRECATED_ENTRY_KEYS
	)
	);
	}

The applyFilters function gets applied to the deprecated definition, so when my plugin adds additional attributes at the top level via a filter, this same filter gets applied to the deprecated definition adding those attributes not allowing the deprecation to change the attributes.

Steps to Reproduce

1. Clone my plugin, build and activate and insert a code block applying a language
2. Clone PR 85 and load the post with old cold block
3. You should see the broken block validation

In a dev version of Gutenberg, you can comment out the settings.deprecated section in registration.js build and load the block again and see validation passes.

It took a fair amount of debugging to figure out what is going on, I'm not quite sure the solution because it looks like if this part is skipped validations break on core/group