Packages: Make usage of core-data explicit

[gziolo]

Description

This PR tries to make usage of @wordpress/core-data more explicit. When evaluating #8354 and trying to update all blocks to not have direct API calls I figured out that:

• we no longer reference @wordpress/api-fetch in the code but we still list it as dependency
• @wordpress/core-data isn't initialized for @wordpress/block-library and @wordpress/editor which might create some issues when using packages outside of WordPress

I also included the change which changes the description of @wordpress/block-library package which we missed last week.

[gziolo]

By the way, @wordpress/editor also uses stores from @wordpress/nux and @wordpress/viewport. They are imported and initialized only because we use some components from those packages in some parts of the editor.

[youknowriad]

I think we should do that for all stores regardless of whether these modules are already imported for components etc... For example editor should import blocks/viewport, nux and core-data etc...

[gziolo]

I asked about that in #8354, I tend to agree with the proposal of making all those imports explicit in the entry file for the package. This way it should be lintable if we agree we want to do it.

[gziolo]

When looking at adding explicit dependencies, I discovered that it would produce cyclic dependency between @wordpress/data and @wordpress/core-data:

https://github.com/WordPress/gutenberg/blob/master/packages/data/src/registry.js#L195-L196

[gziolo]

When looking at adding explicit dependencies, I discovered that it would produce cyclic dependency between @wordpress/data and @wordpress/core-data:

It turns out that:

• select( 'core/data' ) is internal for @wordpress/data
• select( 'core' ) is internal for @wordpress/core-data

It is confusing but is what it is. Nothing to worry about :)

[aduth]

Will review in more detail shortly, but are these all of the data dependencies we have?

There's also a new merge conflict which needs to be resolved.

[gziolo]

I noticed that we should be using "@babel/runtime-corejs2": "7.0.0-beta.56" when rebasing so I included this change, too.

Will review in more detail shortly, but are these all of the data dependencies we have?

I think only editor and block-library use external stores. Otherwise, they are used by the same package which registers them.

[youknowriad]

Clearing the milestone because this has no impact on the WordPress scripts.

[gziolo]

I rebased it with master, can we move forward with it?

I think the long-term solution is going to be established with #8981. However, it's not a priority at the moment.

[youknowriad]

I think edit-post also uses a bunch of stores, should we add theme there as well?

[gziolo]

Added in 2c4f0b0.

[youknowriad]

viewport?

[gziolo]

There is no explicit usage in the module so I missed it ...
I will fix.

We need to figure a more robust way 😄

[aduth]

There is no explicit usage in the module so I missed it ...

This confused me a bit. If there's not explicit usage, the module shouldn't need to define it?

But in looking closer, there is explicit usage:

gutenberg/edit-post/store/effects.js

Line 142 in d7eb4f6

const isMobileViewPort = () => select( 'core/viewport' ).isViewportMatch( '< medium' );

[gziolo]

It was all my fault, I didn't grep properly ...

[youknowriad]

We may have missed some but I'm approving regardless, we can tweak over time until we find a better approach (no global)

[aduth]

There are local changes to master after npm install with these changes. I think we missed an update to package-lock.json.

[gziolo]

I was wondering if there is a way to catch this kind of issue on Travis and fail the build. It isn’t first time when it happens.