Packages: Publish all modules as independent npm packages

[Shelob9]

Issue Overview and Possible Solution

When creating a block, I start with something like this:

const { __ } = wp.i18n;
const { registerBlockType } = wp.blocks; 
const BlockControls = wp.blocks.BlockControls;
const el = wp.element.createElement;

Strong coupling to global state is consistent with traditional WordPress anti-patterns. But it presents the following problems:

1. Gutenberg might not be active (3k active installs) or the site might not be on WordPress 5.0 yet (currently ~77% of WordPress sites are not on the current release series.)
2. Relying on global state makes testing very hard and/or impossible depending on test type/ technology.
3. I may wish to use these components in my plugin or other type of code that isn't strongly-coupled to WordPress and including them via npm and an import statement is how that should work.

Expected Behavior

$ npm i @wordpress/element

import { createElement } from '@wordpress/element';

Current Behavior

const { createElement } = wp.element;

Tasks

• api-request (Add a new @wordpress/api-request package #7018)
• blob (Blob: Extract new blob package out of utils module #6973) - extracted from utils
• blocks - depends on wp.shortcode and window._wpBlocks (Packages: Add the blocks module to the packages folder #8046)
• core-blocks renamed to block-library (Extract Core Blocks to the npm packages folder #8287)
• core-data (Move the Core Data Module to the reusable packages #7222)
• components (Packages: Move the components module partially to the packages folder #7640)
• compose (Packages: Add a new compose package #7948)
• editor (Packages: Extract the editor package #8081)
• edit-post - we don't plan to publish it, this might change
• data (Packages: Move data module to the package maintained by Lerna #6828)
• date (Build: Move date module to packages maintained by Lerna #6658)
• deprecated (Deprecated: Introduce new module with depreaction util #6914) - extracted from utils
• dom (Packages: Extract dom package and make it maintained with Lerna #6758) - extracted from utils
• element (Packages: Move element to packages maintained by Lerna #6756)
• library-export-default-webpack-plugin (Build: Add new Webpack plugin to handle library default export #6935)
• nux (Packages: Extract @wordpress/nux package #8016)
• plugins (Packages: Move Plugins module to packages #7235)
• utils - to be extracted into smaller packages (Editor: Move media upload from utils #7978)
• viewport - depends on components (Packages: Extract viewport package #7975)

[youknowriad]

There is some work being done making Gutenberg modules available as npm packages. This work has started here https://github.com/WordPress/packages (discussions in the #core-js channel). But all modules should not be used as npm packages because:

• Some of them require Server Side logic (injected scripts
• This means each plugin will have its own version, while this acceptable for generic modules like "components" or "i18n" it might not be the case for modules like "blocks" where we need one and only one version (a single block registry)

[Shelob9]

@youknowriad I'm glad to hear this is in progress.

You said Some of them require Server Side logic (injected scripts which is a valid concern, but shouldn't blocks to be sufficiently decoupled from that server-side logic that we can inject our own for testing or non-traditional uses, for example Gutenberg for Drupal content editing :)

[youknowriad]

shouldn't blocks to be sufficiently decoupled from that server-side logic that we can inject our own for testing or non-traditional uses, for example Gutenberg for Drupal content editing :)

That's a valid use-case that I care about as well, making Gutenberg (or the core of Gutenberg) a reusable piece. While I think it's important to follow this direction, it's not a priority for the first release.

[andreiglingeanu]

One valid reason for this is i18n. I'd really love to be able to pull @wordpress/i18n package as a standalone thing. I'm building my own private solution for translations (with having a custom Babel plugin, too) and I'd love to not be having to maintain the wp.i18n lib by myself.

Are you guys considering to get at least the small utilities published in NPM, for everyone in the WP community to be able to use & benefit from them?

[youknowriad]

re you guys considering to get at least the small utilities published in NPM, for everyone in the WP community to be able to use & benefit from them?

Yes, we are. Expect more in the future but there are some utilities available right now. Others like components, i18n, etc. will follow https://www.npmjs.com/org/wordpress

[andreiglingeanu]

One more question is, should I count on the technique of putting the lib globally under wp namespace (wp.i18n, wp.blocks, wp.element) as a viable one? Will that be supported with arrival of Gutenberg into the WP core?

If so, I'd like to be able to remove those dependencies from my bundles in the future and just use the globally available ones.

wp.i18n and wp.element appeals to me a lot. This will allow me to build UIs using React without having to ship the lib itself with the plugin.

[youknowriad]

If so, I'd like to be able to remove those dependencies from my bundles in the future and just use the globally available ones.

Yes, I think so. I think we should think about this module by module because making it available in the global means maintaining backwards compatibility for this global. For example the components module, I'm not sure we'd want to make it global in the future.

[gziolo]

We probably will integrate Lerna into this repository and will publish i18n, block, components, element as packages from here. We would use next tag to inform that they are experimental and bump version every time we do a release for a plugin. Is someone interested to work on this?