Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages: Move data module to the package maintained by Lerna #6828

Merged
merged 10 commits into from
May 30, 2018

Conversation

gziolo
Copy link
Member

@gziolo gziolo commented May 18, 2018

Description

Related issues: #3955, #6594.
Similar: #6658, #6756, #6758.

This PR tries to provide Lerna setup similar to what we have in WordPress/packages. This would allow publishing source code of individual modules to npm to make them available for all plugin developers.

After moving date and element, this PR moves data module to packages folder maintained by Lerna.

This is the first time where a package depends on another Gutenberg package (element).

Open question

data module uses window.localStorage which won't work in non-browser environments. Are we fine with having it included in the initial release? Should we add guard which disable persistence when local storage is not provided?

How has this been tested?

Manually:

  • Removed node_modules folder.
  • npm install
  • npm test
  • npm run dev
  • npm run build
  • npm run package-plugin

Types of changes

Refactoring.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code has proper inline documentation.

@gziolo gziolo self-assigned this May 18, 2018
@gziolo gziolo requested review from ntwb and youknowriad May 18, 2018 12:23
@gziolo gziolo added this to the 3.0 milestone May 18, 2018
@gziolo gziolo added npm Packages Related to npm packages [Type] Refactoring [Package] Data /packages/data labels May 18, 2018
@gziolo gziolo requested a review from a team May 18, 2018 12:27
@youknowriad
Copy link
Contributor

data module uses window.localStorage which won't work in non-browser environments. Are we fine with having it included in the initial release?

For me it's fine. I think it's not even used by default unless you explicitly import the persisting helper.

@youknowriad
Copy link
Contributor

This is the first time where a package depends on another Gutenberg package (element).

Since this is the first packages that users element I think we should discuss how we do JSX. At the moment we're relying on the wp.element.createElement pragma (global variable) but the @wordpress/element package don't generate the global by default and even if does it needs to be imported at least once to generate the global.

So what I propose is to do something similar to React:

  • require import { createElement } from '@wordpress/element' in all files using JSX
  • Update the eslint pragma config to match this change

@@ -1,9 +1,17 @@
# Data
# @wordpress/date
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be @wordpress/data

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy pasta 😃

@gziolo
Copy link
Member Author

gziolo commented May 21, 2018

For me it's fine. I think it's not even used by default unless you explicitly import the persisting helper.

True, however, I added a way to override the default persistence storage with 04e52b0 :)

@gziolo
Copy link
Member Author

gziolo commented May 21, 2018

So what I propose is to do something similar to React:

  • require import { createElement } from '@wordpress/element'` in all files using JSX
    Update the eslint pragma config to match this change

Sounds like a good idea. With the small exception, we should limit Eslint check to packages folder. We also need to make sure Eslint doesn't complain when createElement is included when used with JSX powered file.

@gziolo
Copy link
Member Author

gziolo commented May 23, 2018

require import { createElement } from '@wordpress/element' in all files using JSX
Update the eslint pragma config to match this change

Done with 6c26c4b.

There is one more thing which popped up after rebase. We need to move deprecated util to its own package.

@gziolo
Copy link
Member Author

gziolo commented May 23, 2018

There is one more thing which popped up after rebase. We need to move deprecated util to its own package.

Introduced also @wordpress/devtools package. We might want to find a better name for it. I'm happy to update it if you have better ideas.

@youknowriad
Copy link
Contributor

@gziolo Do you think it's possible to extract the devtools package to its own PR, I feel it could make it way quicker than the data one?

@gziolo
Copy link
Member Author

gziolo commented May 23, 2018

@gziolo Do you think it's possible to extract the devtools package to its own PR, I feel it could make it way quicker than the data one?

Sure thing - it is in its own commit - doing it now.

@gziolo
Copy link
Member Author

gziolo commented May 23, 2018

@youknowriad - I opened #6914 with devtools part, I will rebase this PR as soon as the other one lands.

@gziolo
Copy link
Member Author

gziolo commented May 28, 2018

deprecated packages is now merged into master and this PR was rebased to use it.

},
},
},
],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we still need a similar config for babel to generate the Right JS (instead of using the global)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed, I will look into it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be fixed with f7afc46.

Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 I'd appreciate a confirmation from @mtias or @aduth That the explicit import.

Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with explicit createElement pragma. Would hope we'd apply it consistently eventually.

@@ -36,6 +36,8 @@ const DONE = chalk.reset.inverse.bold.green( ' DONE ' );
*/
const babelDefaultConfig = require( '@wordpress/babel-preset-default' );
babelDefaultConfig.babelrc = false;
// TODO: It should become the default value when all modules are moved to packages.
babelDefaultConfig.plugins[ 1 ][ 1 ].pragma = 'createElement';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Must we mutate? Can we assign into a new object? Not sure what would break, but certainly seems prone to cause breakage as implemented.
  2. Similarly, the [ 1 ][ 1 ] assumes a very specific order which, while we maintain and is unlikely to change anytime soon, is certainly incredibly fragile.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opted for a quick fix with the hope that it won't last for long. I guess it is going to be around for a couple of weeks at least so I'm happy to provide more solid processing of default Babel config.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fdb107e - done

Install the module

```bash
npm install @wordpress/data@next --save
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we @next ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, we can publish alpha without using dev :)

"url": "https://github.com/WordPress/gutenberg/issues"
},
"main": "src/index.js",
"dependencies": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests use deep-freeze and enzyme. Do we need to reflect that anywhere in this file as a dependency?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that we are going to move those packages elsewhere one day, let's keep all dependencies listed. I will add them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot that enzyme is already included in @wordpress/scripts by design.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should be explicit :) If we use enzyme directly here in our tests, it should be a direct dependency

{
"name": "@wordpress/data",
"version": "0.0.1",
"description": "Data Redux module for WordPress",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation clearly states:

The data module is built upon and shares many of the same core principles of Redux, but shouldn't be mistaken as merely Redux for WordPress

Is this not in contradiction?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, I will update.

@@ -8,6 +8,18 @@ import deprecated from '@wordpress/deprecated';
*/
import { get } from 'lodash';

// Defaults to the local storage.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we default to a broken (error-throwing) state for Node environments where this package is used?

It's probably a larger dependency than we'd want, but something like Store.js is a good abstraction for this sort of thing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, you can make it work by using setter method introduced in this PR:

import store from 'store';

setPersistenceStorage( store );

It isn't ideal, needs to be documented but should allow us to move forward. I will add the following example in the README file.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's tackle it seperately as we don't have any docs for loadAndPersist anyways.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened #7015 to solve it.

@gziolo
Copy link
Member Author

gziolo commented May 30, 2018

Let's get it in and see how it goes 🎉

@gziolo gziolo merged commit c1fffb1 into master May 30, 2018
@gziolo gziolo deleted the update/data-package branch May 30, 2018 17:58
@gziolo gziolo modified the milestones: 3.1, 3.0 May 30, 2018
@ellatrix ellatrix added [Type] Code Quality Issues or PRs that relate to code quality and removed [Type] Code Quality Issues or PRs that relate to code quality labels Nov 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
npm Packages Related to npm packages [Package] Data /packages/data [Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants