Update wp.editor references

[ryelle]

Needs a gutenberg reference, but some things(?) in wp.editor are moving to wp.blockEditor, and it's throwing warnings with the latest version of the gb plugin. Will need to see about backwards compat, but for example:

wp.editor.BlockControls is deprecated and will be removed. Please use wp.blockEditor.BlockControls instead.

wp.editor.InspectorControls is deprecated and will be removed. Please use wp.blockEditor.InspectorControls instead.

wp.editor.InnerBlocks is deprecated and will be removed. Please use wp.blockEditor.InnerBlocks instead.

[nerrad]

Related pull where changes were introduced: WordPress/gutenberg#14112
Related dev doc: https://make.wordpress.org/core/2019/04/09/the-block-editor-javascript-module-in-5-2/

[nerrad]

I don't think this should be in the icebox. While the warnings are deprecated warnings, with the pending release of WordPress 5.3 we'll soon have two major versions of WordPress out on the wild where Woo Blocks will throw deprecation warnings because of our incorrect usage of imports from @wordpress/editor.

We have a couple options:

• wait until WooCommerce core updates minimum WordPress version required to 5.2+
• Create our own wrapper bundle for the wp.blockEditor external and if that's not present, export wp.editor instead. Then we can alias all imports in our own scripts to that export (@woocommerce/block-editor-compat).

The first option is the easiest of course and results in less code churn. But it does mean that we are seeing these deprecated notices for a while. Since merging @woocommerce/admin to Woo Core will be predicated by a minimum version bump to WordPress 5.2, this means this option is more viable.

The second option is doable and would have the immediate benefit of ensuring we're always using the correct imports for whatever environment the blocks is loaded in (and thus eliminating the deprecation notices). The downsides are the code-churn for replacing all existing imports and the potential confusion with the seeing @woocommerce/block-editor-compat as imports.

I'm leaning towards the first option but I also could probably implement the second option in half a day to a day's work.

At a minimum though, I think this should be in the backlog pipeline, not the icebox - so I've moved it if that's okay?

cc @pmcpinto

[Aljullu]

The first option also seems the best to me, we avoid polluting the code and having to make the change twice. It comes with the drawback that we will get warnings for some time, but I guess most users will never notice that.

In case it helps, there was some discussion about this in: paAmJe-tx-p2.

[pmcpinto]

At a minimum though, I think this should be in the backlog pipeline, not the icebox - so I've moved it if that's okay?

@nerrad thanks for the explanation. I'm ok with moving it to the backlog. I think it was Mike that moved it to the Icebox, I don't know what was the reason behind that.

[mikejolley]

@nerrad just raising this again for your 👀 - I think we talked about this min version being bumped for our next release, so that would be a good time to fix this.

[nerrad]

OH yaaa. It would be a good time! Let's do it. It doesn't increase scope that much because it's mostly just correcting what package (external) components point to. Will be nice to get rid of the warning :)