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?

[Shelob9]

I made a PHP app that copies all of Gutenberg's built JS/CSS files and publishes them as an npm package

Not sure if this approach makes sense yet or not, but if I can figure out how to get it work with webpack, I can use Travis to run the app's build command every-time a new tag is added to Gutenberg and then publish the same tag to npm.

[gziolo]

We should publish all Gutenberg modules (except edit-post) as individual packages to npm later this month. I’ll be working on it starting next week the latest. I’m not sure if using built files is the way to go in general but might be beneficial in your case. My thinking is that we should publish sources as they are after each new version is tagged.

[c-shultz]

We should publish all Gutenberg modules (except edit-post) as individual packages to npm later this month.

That would be great! That would definitely solve the dependency issues I was running into with unit testing a Jetpack module that depend on Gutenberg's data API.

[Shelob9]

I'm testing with

import {registerStore} from "@wordpress/data";

    describe( 'wp.data import', () => {
        it( 'registerStore is available',  () => {
            expect(typeof registerStore ).toEqual('function');
        });

        it( 'registerStore works',  () => {
            const initalState = {
                hi: 'Roy'
            };
            expect( registerStore( 'testStore', {
                reducer( state = initalState, action ) {
                    //reduce nothing
                    return state;
                },
            }).getState() ).toEqual(initalState);
        });


    })
});

Both tests are passing :)

[gziolo]

I'm moving plugins module to packages and I noticed the same issue like in dom module:

export * from './components';
export * from './api';

transpiles to commonjs with the unexpected:

import _Object$defineProperty from 'babel-runtime/core-js/object/define-property';
import _Object$keys from 'babel-runtime/core-js/object/keys';

[gziolo]

#7832 upgrades Babel to v7 which will resolve all the issues we have with the transpiled code 🎉

[gziolo]

I published last of the planned packages with e1811b2

All packages can be downloaded from npm using the stable version. Let's open a follow up issues when they are discovered and iterate on the current setup independently.