Packages: Make usage of core-data explicit#8911
Conversation
|
By the way, |
|
I think we should do that for all stores regardless of whether these modules are already imported for components etc... For example |
|
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. |
|
When looking at adding explicit dependencies, I discovered that it would produce cyclic dependency between |
It turns out that:
It is confusing but is what it is. Nothing to worry about :) |
|
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. |
35f143b to
19436fa
Compare
|
I noticed that we should be using
I think only |
|
Clearing the milestone because this has no impact on the WordPress scripts. |
19436fa to
b996fa2
Compare
|
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. |
| import '@wordpress/blocks'; | ||
| import '@wordpress/core-data'; | ||
| import '@wordpress/nux'; | ||
| import '@wordpress/viewport'; |
There was a problem hiding this comment.
I think edit-post also uses a bunch of stores, should we add theme there as well?
b996fa2 to
2c4f0b0
Compare
| */ | ||
| import '@wordpress/core-data'; | ||
| import '@wordpress/editor'; | ||
| import '@wordpress/nux'; |
There was a problem hiding this comment.
There is no explicit usage in the module so I missed it ...
I will fix.
We need to figure a more robust way 😄
There was a problem hiding this comment.
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
There was a problem hiding this comment.
It was all my fault, I didn't grep properly ...
youknowriad
left a comment
There was a problem hiding this comment.
We may have missed some but I'm approving regardless, we can tweak over time until we find a better approach (no global)
| "dependencies": { | ||
| "@babel/runtime": "^7.0.0-beta.52", | ||
| "@wordpress/api-fetch": "file:../api-fetch", | ||
| "@babel/runtime-corejs2": "7.0.0-beta.56", |
There was a problem hiding this comment.
There are local changes to master after npm install with these changes. I think we missed an update to package-lock.json.
There was a problem hiding this comment.
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.
Description
This PR tries to make usage of
@wordpress/core-datamore explicit. When evaluating #8354 and trying to update all blocks to not have direct API calls I figured out that:@wordpress/api-fetchin the code but we still list it as dependency@wordpress/core-dataisn't initialized for@wordpress/block-libraryand@wordpress/editorwhich might create some issues when using packages outside of WordPressI also included the change which changes the description of
@wordpress/block-librarypackage which we missed last week.