{"id":5860,"date":"2020-11-18T14:33:00","date_gmt":"2020-11-18T14:33:00","guid":{"rendered":"https:\/\/azoora.com\/blog\/?p=5860"},"modified":"2020-11-22T15:51:15","modified_gmt":"2020-11-22T15:51:15","slug":"reusing-functionality-for-wordpress-plugins-with-blocks","status":"publish","type":"post","link":"https:\/\/azoora.com\/blog\/code\/reusing-functionality-for-wordpress-plugins-with-blocks\/","title":{"rendered":"Reusing Functionality for WordPress Plugins with Blocks"},"content":{"rendered":"\n<p>When creating a plugin shipping one or more blocks for the <strong>WordPress<\/strong> editor, what is the best way to organize the plugin as to make its different components reusable?<\/p>\n\n\n\n<p>The block directory (launched in WordPress 5.5) enables to install a block while writing a post in the WordPress editor. This feature might persuade plugin developers to ship their blocks through single-block plugins, which can be installed through the block directory, instead of through multi-block plugins, which cannot.<\/p>\n\n\n\n<p>However, there are many situations for which multi-block plugins shouldn\u2019t be transformed to a series of single-block plugins, such as when:<\/p>\n\n\n\n<ul><li>The blocks are similar, and share plenty of logic<\/li><li>The plugin implements a custom post type (CPT), and we want to enhance it with its own set of blocks<\/li><li>Shipping many blocks together makes the product better than shipping them separately<\/li><li>We don\u2019t need to publish our blocks to the block directory, as when an agency creates a block for its clients<\/li><\/ul>\n\n\n\n<p>I find the first item, when blocks share plenty of logic, of particular interest. Moreover, also single-block plugins could need to provide common logic, not to blocks, but to the different components within the block.<\/p>\n\n\n\n<p>In this article, we will tackle two considerations:<\/p>\n\n\n\n<ol><li>What is the best way to create and manage a multi-block plugin?<\/li><li>What is the most effective way to reuse code within a (single or multi-block) plugin?<\/li><\/ol>\n\n\n\n<h2 id=\"h-repurposing-wordpress-create-block-to-create-multi-block-plugins\">Repurposing&nbsp;<code>@wordpress\/create-block<\/code>&nbsp;to create multi-block plugins<\/h2>\n\n\n\n<p><a href=\"https:\/\/developer.wordpress.org\/block-editor\/packages\/packages-create-block\/\"><code>@wordpress\/create-block<\/code><\/a>, the official package to scaffold blocks created and maintained by the team developing Gutenberg, tackles most of the complexities associated with modern JavaScript projects, allowing us to focus on the block\u2019s business logic.<\/p>\n\n\n\n<p>For instance,\u00a0<code>@wordpress\/create-block<\/code>\u00a0provides a\u00a0default configuration of <a href=\"https:\/\/webpack.js.org\/\">webpack<\/a>\u00a0(the module bundler at the core of Gutenberg), designed to cover the majority of cases, and we can\u00a0override the configuration\u00a0whenever we need more control.<\/p>\n\n\n\n<p>Currently,\u00a0<code>@wordpress\/create-block<\/code>\u00a0can only tackle creating single-block plugins, not multi-block plugins (hopefully, in the not-so-distant future, it will be possible to\u00a0<a href=\"https:\/\/github.com\/WordPress\/gutenberg\/issues\/23514#issuecomment-650910611\">generate any type of output through templates<\/a>). However, with a bit of extra effort, we can already leverage\u00a0<code>@wordpress\/create-block<\/code> to create multi-block plugins\u00a0too.<\/p>\n\n\n\n<p>The goal is to create a folder&nbsp;<code>blocks\/<\/code>&nbsp;within the plugin, and then create there all the required blocks, all of them independent from each other. The structure of the plugin will be this one:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>my-plugin\/<\/code><code>\u2502<\/code><code>\u251c\u2500\u2500blocks\/<\/code><code>\u2502 \u251c\u2500\u2500block1\/<\/code><code>\u2502 \u251c\u2500\u2500block2\/<\/code><code>\u2502 \u2514\u2500\u2500block3\/<\/code><code>\u2502<\/code><code>\u2514\u2500\u2500 my-plugin.php<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 id=\"h-using-packages-to-share-code-among-the-blocks\">Using packages to share code among the blocks<\/h2>\n\n\n\n<p>Different blocks in the plugin may require some common functionality.<\/p>\n\n\n\n<p>For instance, I have built a plugin which uses blocks to configure its several custom post types, one custom block per CPT. On their left side, the configuration blocks use a common component to select the elements to configure, which are shared across CPTs, and on the right side, each block displays the custom properties for that CPT:<\/p>\n\n\n\n<p><\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img data-attachment-id=\"5861\" data-permalink=\"https:\/\/azoora.com\/blog\/code\/reusing-functionality-for-wordpress-plugins-with-blocks\/attachment\/configuration-block-01\/#main\" data-orig-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-01.png\" data-orig-size=\"1024,380\" data-comments-opened=\"1\" data-image-meta=\"{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}\" data-image-title=\"configuration-block-01\" data-image-description=\"\" data-medium-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-01-300x111.png\" data-large-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-01-1024x380.png\" loading=\"lazy\" width=\"1024\" height=\"380\" src=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-01-1024x380.png\" alt=\"\" class=\"wp-image-5861\" srcset=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-01.png 1024w, https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-01-300x111.png 300w, https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-01-768x285.png 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><figcaption> A configuration block, with shared functionality<\/figcaption><\/figure>\n\n\n\n<figure class=\"wp-block-image size-large\"><img data-attachment-id=\"5862\" data-permalink=\"https:\/\/azoora.com\/blog\/code\/reusing-functionality-for-wordpress-plugins-with-blocks\/attachment\/configuration-block-02\/#main\" data-orig-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-02.png\" data-orig-size=\"1024,413\" data-comments-opened=\"1\" data-image-meta=\"{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}\" data-image-title=\"configuration-block-02\" data-image-description=\"\" data-medium-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-02-300x121.png\" data-large-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-02-1024x413.png\" loading=\"lazy\" width=\"1024\" height=\"413\" src=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-02-1024x413.png\" alt=\"\" class=\"wp-image-5862\" srcset=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-02.png 1024w, https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-02-300x121.png 300w, https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/configuration-block-02-768x310.png 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><figcaption> Another configuration block, with shared functionality<\/figcaption><\/figure>\n\n\n\n<p>That shared functionality on the left side, where should it live? On both blocks? On only one of them, and the other one access it from there? Or where else?<\/p>\n\n\n\n<p>The best solution is to extract the shared logic out from the blocks, put it into packages, and have the blocks import the functionalities from the packages. We can create as many packages as needed, each of them containing all the functionality for some specific topic or category (eg: data access and storage, user interface, internationalization, etc).<\/p>\n\n\n\n<p>We place all packages under a&nbsp;<code>packages\/<\/code>&nbsp;folder in the plugin. The plugin\u2019s structure now becomes:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>my-plugin\/<\/code><code>\u2502<\/code><code>\u251c\u2500\u2500blocks\/<\/code><code>\u2502 \u251c\u2500\u2500block1\/<\/code><code>\u2502 \u251c\u2500\u2500block2\/<\/code><code>\u2502 \u2514\u2500\u2500block3\/<\/code><code>\u2502<\/code><code>\u251c\u2500\u2500packages\/<\/code><code>\u2502 \u251c\u2500\u2500package1\/<\/code><code>\u2502 \u2514\u2500\u2500package2\/<\/code><code>\u2502<\/code><code>\u2514\u2500\u2500 my-plugin.php<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>There is a potential issue we must deal with. When running\u00a0<code>npm run build<\/code>\u00a0to compile the block, webpack will be loading code that involves more than one webpack configuration: the one from the block, and the configuration from each of the referenced packages. And this\u00a0can create conflict.<\/p>\n\n\n\n<p>To solve it, we need to create a custom&nbsp;<code>webpack.config.js<\/code>&nbsp;file for the block (if it doesn\u2019t already exist):<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>my-plugin\/<\/code><code>\u2514\u2500\u2500blocks\/<\/code><code>\u2514\u2500\u2500my-block\/<\/code><code>\u2514\u2500\u2500webpack.config.js<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>And, within this file, we must define a unique value for property&nbsp;<code>config.output.jsonpFunction<\/code>&nbsp;(otherwise, all blocks use the default name&nbsp;<code>\"webpackJsonp\"<\/code>):<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>const config = require( <\/code><code>'@wordpress\/scripts\/config\/webpack.config'<\/code> <code>);<\/code>&nbsp;<code>config.output.jsonpFunction = <\/code><code>\"ADD_SOME_UNIQUE_NAME_HERE\"<\/code><code>;<\/code>&nbsp;<code>module.exports = config;<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 id=\"h-creating-and-referencing-a-package\">Creating and referencing a package<\/h2>\n\n\n\n<p>Similar to a block, a package is also a modern JavaScript project, so it is affected by the same complex underpinnings as blocks are.<\/p>\n\n\n\n<p>Concerning blocks, these complexities are taken care of by the&nbsp;<code>@wordpress\/create-block<\/code>&nbsp;block-scaffolding tool, through the structure of the block, and the dependency on&nbsp;<a href=\"https:\/\/github.com\/WordPress\/gutenberg\/tree\/master\/packages\/scripts\"><code>@wordpress\/scripts<\/code><\/a>&nbsp;declared on the block\u2019s&nbsp;<code>package.json<\/code>&nbsp;file.<\/p>\n\n\n\n<p>So, let\u2019s copy these over to the package. The structure of the package is this one:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>my-package\/<\/code><code>\u251c\u2500\u2500src\/<\/code><code>\u2502 \u2514\u2500\u2500index.js<\/code><code>\u2514\u2500\u2500 package.json<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>The contents of&nbsp;<code>package.json<\/code>&nbsp;are the same ones as when creating a new block, plus the addition of entry&nbsp;<code>\"module\": \"src\/index.js\"<\/code>, required to tell the blocks where to find the source code for the modules to import.<\/p>\n\n\n\n<p>It is a good idea to group the plugin\u2019s packages under the plugin namespace&nbsp;<code>@my-plugin<\/code>. Then, the package name becomes&nbsp;<code>\"@my-plugin\/my-package\"<\/code>:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>{<\/code><code>\"name\": \"@my-plugin\/my-package\",<\/code><code>\"version\": \"0.1.0\",<\/code><code>\"description\": \"Common components for the blocks in the plugin\",<\/code><code>\"author\": \"Your name\",<\/code><code>\"license\": \"Your license\",<\/code><code>\"main\": \"build\/index.js\",<\/code><code>\"module\": \"src\/index.js\",<\/code><code>\"scripts\": {<\/code><code>\"build\": \"wp-scripts build\",<\/code><code>\"format:js\": \"wp-scripts format-js\",<\/code><code>\"lint:css\": \"wp-scripts lint-style\",<\/code><code>\"lint:js\": \"wp-scripts lint-js\",<\/code><code>\"start\": \"wp-scripts start\",<\/code><code>\"packages-update\": \"wp-scripts packages-update\"<\/code><code>},<\/code><code>\"devDependencies\": {<\/code><code>\"@wordpress\/scripts\": \"^12.1.0\"<\/code><code>}<\/code><code>}<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>In order to import modules from a package, the block needs to add the package as a dependency. Since blocks and packages live in the same plugin, the dependency can point to a local folder.<\/p>\n\n\n\n<p>To do this, in a terminal window browse to the block folder:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>cd<\/code> <code>path-to-my-plugin<\/code><code>\/blocks\/my-block<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>And then execute:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>npm <\/code><code>install<\/code> <code>--save-dev ..\/..<\/code><code>\/packages\/my-package<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>As a result, we can observe that the block\u2019s&nbsp;<code>package.json<\/code>&nbsp;will contain a local dependency to the package, like this:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>{<\/code><code>\"devDependencies\": {<\/code><code>\"@my-plugin\/my-package\": \"file:..\/..\/packages\/my-package\"<\/code><code>}<\/code><code>}<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>And in the block\u2019s&nbsp;<code>node_modules\/<\/code>&nbsp;folder, there will be a new symlink&nbsp;<code>@my-plugin\/my-package<\/code>&nbsp;pointing to the package\u2019s source folder.<\/p>\n\n\n\n<p>If we decide to, a package can also be published to the&nbsp;<a href=\"https:\/\/www.npmjs.com\/\">npm directory<\/a>, as to make it accessible for other parties too, not just to be used within our plugin. Then, these other parties can install it as any other dependency:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>npm <\/code><code>install<\/code> <code>--save-dev @my-plugin<\/code><code>\/my-package<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Within the same plugin, though, it makes sense to install the package as a local dependency, because it allows the block to access the code from the package directly from its source, without needing to publish a new version to the registry first, making development much faster.<\/p>\n\n\n\n<h2 id=\"h-importing-modules-from-the-package\">Importing modules from the package<\/h2>\n\n\n\n<p>Let\u2019s say that a component&nbsp;<code>&lt;CustomSelect&gt;<\/code>&nbsp;stored under&nbsp;<code>block1<\/code>&nbsp;is then also required by&nbsp;<code>block2<\/code>. To make it accessible by all blocks, we extract the component out from the block, and move it to package&nbsp;<code>@my-plugin\/components<\/code>:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>components\/<\/code><code>\u2514\u2500\u2500src\/<\/code><code>\u251c\u2500\u2500custom-select.js<\/code><code>\u2514\u2500\u2500index.js<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Then, we&nbsp;<a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/JavaScript\/Reference\/Statements\/export\"><code>export<\/code><\/a>&nbsp;the component from the package\u2019s&nbsp;<code>index.js<\/code>:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>export<\/code> <code>{ CustomSelect } from <\/code><code>'.\/custom-select'<\/code><code>;<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>To make sure that the package compiles well, and that the component is being exported, we step on the package folder in the terminal, and execute:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>npm start<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>(Before then, we must have downloaded all the JavaScript dependencies in the&nbsp;<code>node_modules\/<\/code>&nbsp;folder, done by running&nbsp;<code>npm install<\/code>.)<\/p>\n\n\n\n<p>The output in the console will indicate if there is any error in the code, and what files were included:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img data-attachment-id=\"5863\" data-permalink=\"https:\/\/azoora.com\/blog\/code\/reusing-functionality-for-wordpress-plugins-with-blocks\/attachment\/npm-start-package\/#main\" data-orig-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/npm-start-package.png\" data-orig-size=\"1024,829\" data-comments-opened=\"1\" data-image-meta=\"{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}\" data-image-title=\"npm-start-package\" data-image-description=\"\" data-medium-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/npm-start-package-300x243.png\" data-large-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/npm-start-package-1024x829.png\" loading=\"lazy\" width=\"1024\" height=\"829\" src=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/npm-start-package-1024x829.png\" alt=\"\" class=\"wp-image-5863\" srcset=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/npm-start-package.png 1024w, https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/npm-start-package-300x243.png 300w, https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/npm-start-package-768x622.png 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><figcaption> Building a package with NPM start<\/figcaption><\/figure>\n\n\n\n<p>The package is compiled under file&nbsp;<code>build\/index.js<\/code>, which is not referenced by the block, so we can delete it safely if we decide to. The package\u2019s structure now looks like this:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>components\/<\/code><code>\u251c\u2500\u2500src\/<\/code><code>\u2502 \u251c\u2500\u2500custom-select.js<\/code><code>\u2502 \u2514\u2500\u2500index.js<\/code><code>\u2514\u2500\u2500build\/<\/code><code>\u2514\u2500\u2500index.js<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Finally, we can&nbsp;<a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/JavaScript\/Reference\/Statements\/import\"><code>import<\/code><\/a>&nbsp;and use the component in our block:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>import<\/code> <code>{ CustomSelect } from <\/code><code>'@my-plugin\/components'<\/code><code>;<\/code>&nbsp;<code>const BlockCustomSelect = () =&gt; (<\/code><code>&lt;CustomSelect<\/code><code>options={ [<\/code><code>\"red\"<\/code><code>, <\/code><code>\"green\"<\/code><code>, <\/code><code>\"blue\"<\/code><code>] }<\/code><code>\/&gt;<\/code><code>)<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 id=\"h-managing-the-node_modules-oversize\">Managing the node_modules oversize<\/h2>\n\n\n\n<p>All blocks and packages in the plugin are independent from each other, which means that each of them has its own&nbsp;<code>package.json<\/code>&nbsp;file, and will require its own&nbsp;<code>node_modules\/<\/code>&nbsp;folder for storing its JavaScript dependencies.<\/p>\n\n\n\n<p>This is a problem, because the\u00a0<code>node_modules\/<\/code>\u00a0folder can demand an incredibly big amount of space, as this famous image makes clear:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img data-attachment-id=\"5864\" data-permalink=\"https:\/\/azoora.com\/blog\/code\/reusing-functionality-for-wordpress-plugins-with-blocks\/attachment\/heaviest-objects-in-universe\/#main\" data-orig-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/heaviest-objects-in-universe.jpg\" data-orig-size=\"990,712\" data-comments-opened=\"1\" data-image-meta=\"{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}\" data-image-title=\"heaviest-objects-in-universe\" data-image-description=\"\" data-medium-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/heaviest-objects-in-universe-300x216.jpg\" data-large-file=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/heaviest-objects-in-universe.jpg\" loading=\"lazy\" width=\"990\" height=\"712\" src=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/heaviest-objects-in-universe.jpg\" alt=\"\" class=\"wp-image-5864\" srcset=\"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/heaviest-objects-in-universe.jpg 990w, https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/heaviest-objects-in-universe-300x216.jpg 300w, https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/heaviest-objects-in-universe-768x552.jpg 768w\" sizes=\"(max-width: 990px) 100vw, 990px\" \/><figcaption> Heaviest objects in the universe<\/figcaption><\/figure>\n\n\n\n<p>Then, if our plugin has 10 blocks, it will require 10&nbsp;<code>node_modules\/<\/code>&nbsp;folders for development, which can make our computers quickly run out of space.<\/p>\n\n\n\n<p>A solution to this problem is to keep a single&nbsp;<code>node_modules\/<\/code>&nbsp;folder containing all the dependencies used by all blocks, and then create a symlink (which is a pointer to some file or folder) under every block\u2019s directory, pointing to this single&nbsp;<code>node_modules\/<\/code>&nbsp;folder (the symlink must have name&nbsp;<code>node_modules<\/code>).<\/p>\n\n\n\n<p>For this strategy to work, all blocks must have the same version of their dependencies. For instance, if a block depends on the latest version of&nbsp;<code>@wordpress\/scripts<\/code>, which is&nbsp;<code>12.1.0<\/code>, then all blocks depending on&nbsp;<code>@wordpress\/scripts<\/code>&nbsp;must also use this same version.<\/p>\n\n\n\n<p>Forcing blocks to use the same version for dependencies takes some independence away from the blocks. However, it also provides the plugin with integrity, since it removes the chance of some error arising from interacting with different versions of the same dependency.<\/p>\n\n\n\n<p>Let\u2019s put this solution into practice. Since the&nbsp;<code>node_modules\/<\/code>&nbsp;folder is required only when developing the plugin, we can create a folder&nbsp;<code>development\/<\/code>&nbsp;in the root of the plugin (at the same level of&nbsp;<code>blocks\/<\/code>&nbsp;and&nbsp;<code>packages\/<\/code>), with a&nbsp;<code>package.json<\/code>&nbsp;file containing all the dependencies from all the blocks:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>my-plugin\/<\/code><code>\u2502<\/code><code>\u251c\u2500\u2500blocks\/<\/code><code>\u2502 \u251c\u2500\u2500block1\/<\/code><code>\u2502 \u2502 \u2514\u2500\u2500package.json<\/code><code>\u2502 \u251c\u2500\u2500block2\/<\/code><code>\u2502 \u2502 \u2514\u2500\u2500package.json<\/code><code>\u2502 \u2514\u2500\u2500block3\/<\/code><code>\u2502&nbsp;&nbsp; \u2514\u2500\u2500package.json<\/code><code>\u2502<\/code><code>\u251c\u2500\u2500development\/<\/code><code>\u2502 \u2514\u2500\u2500package.json<\/code><code>\u2502<\/code><code>\u251c\u2500\u2500packages\/<\/code><code>\u2502 \u251c\u2500\u2500package1\/<\/code><code>\u2502 \u2502 \u2514\u2500\u2500package.json<\/code><code>\u2502 \u2514\u2500\u2500package2\/<\/code><code>\u2502&nbsp;&nbsp; \u2514\u2500\u2500package.json<\/code><code>\u2502<\/code><code>\u2514\u2500\u2500 my-plugin.php<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Then, we download install all JavaScript dependencies, by executing in the terminal:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>$ <\/code><code>cd<\/code> <code>path-to-my-plugin<\/code><code>\/development<\/code><code>$ npm <\/code><code>install<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>All the dependencies are now stored under the single folder&nbsp;<code>development\/node_modules\/<\/code>:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>my-plugin\/<\/code><code>\u2514\u2500\u2500development\/<\/code><code>\u251c\u2500\u2500node_modules\/<\/code><code>\u2502&nbsp; \u251c\u2500\u2500dependency1\/<\/code><code>\u2502&nbsp; \u251c\u2500\u2500dependency2\/<\/code><code>\u2502&nbsp; \u2514\u2500\u2500dependency3\/<\/code><code>\u2514\u2500\u2500package.json<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Next, let\u2019s have each block use this single&nbsp;<code>node_modules\/<\/code>&nbsp;folder by symlinking to it. For this, we step on each block directory, and execute:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>ln<\/code> <code>-snf ..\/..<\/code><code>\/development\/node_modules<\/code> <code>.<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Creating the symlinks for all blocks can be automated. The following bash script, stored as&nbsp;<code>development\/create-symlinks.sh<\/code>, iterates through all the directories under&nbsp;<code>blocks\/<\/code>, and executes the&nbsp;<code>ln<\/code>&nbsp;command to create the symlink on each of them:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>#!\/bin\/bash<\/code><code># Create the symlinks for all blocks in the plugin to the single node_modules\/ folder<\/code><code># Make sure package.json contains ALL dependencies needed for all blocks<\/code>&nbsp;<code># Directory of the bash script<\/code><code>DIR=$(<\/code><code>cd<\/code> <code>$(<\/code><code>dirname<\/code> <code>${BASH_SOURCE[0]}) &amp;amp;&amp;amp; <\/code><code>pwd<\/code><code>)<\/code>&nbsp;<code># Single node_modules\/ folder<\/code><code>NODE_MODULES_DIR=<\/code><code>\"$DIR\/node_modules\/\"<\/code>&nbsp;<code># Function `createSymlinks` will create a 'node_modules\/' symlink under every subfolder in the current directory<\/code><code>createSymlinks(){<\/code><code># Iterate all subdirectories (which are the blocks)<\/code><code>for<\/code> <code>file<\/code> <code>in<\/code> <code>.\/*<\/code><code>do<\/code><code>if<\/code> <code>[ -d <\/code><code>\"$file\"<\/code> <code>]; <\/code><code>then<\/code><code># Create symlink<\/code><code>ln<\/code> <code>-snf <\/code><code>\"$NODE_MODULES_DIR\"<\/code> <code>\"$file\"<\/code><code>fi<\/code><code>done<\/code><code>}<\/code>&nbsp;<code># Step on the root folder where all blocks are located<\/code><code>cd<\/code> <code>\"$DIR\/..\/blocks\/\"<\/code>&nbsp;<code># Create the symlinks for all the blocks<\/code><code>createSymlinks<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>The bash script is executed like this:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>bash<\/code> <code>-x path-to-my-plugin<\/code><code>\/development\/create-symlinks<\/code><code>.sh<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>This script creates symlinks for blocks, but not for packages. This is because, for some reason unknown to me (possibly a bug with Node.js, or maybe some incompatibility with Gutenberg\u2019s dependencies), the block is not built correctly when it references packages which symlink to the&nbsp;<code>node_modules\/<\/code>&nbsp;folder.<\/p>\n\n\n\n<h2 id=\"h-automating-building-blocks\">Automating building blocks<\/h2>\n\n\n\n<p>Once development is ready, we need to build the block for production. This is done by browsing to the block directory in the terminal, and then executing:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>npm run build<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>This command will produce the optimized script file&nbsp;<code>build\/index.js<\/code>, and generate the sylesheets&nbsp;<code>build\/index.css<\/code>&nbsp;and&nbsp;<code>build\/style-index.css<\/code>.<\/p>\n\n\n\n<p>If we have many blocks in the plugin, this can become tedious. However, this task can also be automated with a bash script, stored as&nbsp;<code>development\/build-all-blocks.sh<\/code>:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>#!\/bin\/bash<\/code><code># This bash script builds all the blocks<\/code>&nbsp;<code># Directory of the bash script<\/code><code>DIR=$(<\/code><code>cd<\/code> <code>$( <\/code><code>dirname<\/code> <code>${BASH_SOURCE[0]}) &amp;amp;&amp;amp; <\/code><code>pwd<\/code><code>)<\/code>&nbsp;<code># Function `buildScripts` will run `npm run build` on all subfolders in the current directory<\/code><code>buildScripts(){<\/code><code>for<\/code> <code>file<\/code> <code>in<\/code> <code>.\/*<\/code><code>do<\/code><code>if<\/code> <code>[ -d <\/code><code>\"$file\"<\/code> <code>]; <\/code><code>then<\/code><code>cd<\/code> <code>\"$file\"<\/code><code>npm run build<\/code><code>cd<\/code> <code>..<\/code><code>fi<\/code><code>done<\/code><code>}<\/code>&nbsp;<code># Step on the root folder where all blocks are located<\/code><code>cd<\/code> <code>\"$DIR\/..\/blocks\/\"<\/code>&nbsp;<code># Build all blocks<\/code><code>buildScripts<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 id=\"h-automating-publishing-packages\">Automating publishing packages<\/h2>\n\n\n\n<p>If we have many packages in our plugin, and we decide to expose them to 3rd parties through the npm registry, we can use a specialized tool for this.<\/p>\n\n\n\n<p><strong><a href=\"https:\/\/lerna.js.org\/\">Lerna<\/a>\u00a0<\/strong>is a tool that optimizes the workflow around managing multi-package repositories. It enables to publish many packages together, running a single command:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><code>lerna publish<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 id=\"h-conclusion\">Conclusion<\/h2>\n\n\n\n<p>The recently launched block directory works with single-block plugins only. However, it doesn\u2019t always make sense to ship all our functionality through a series of single-block plugins, and using a multi-block plugin is still more suitable.<\/p>\n\n\n\n<p>In addition, on both multi-block and single-block plugins we may find shared code, reused across blocks and components. Distributing this code through packages, available not just to our plugin but also to 3rd parties, is a sensible approach.<\/p>\n\n\n\n<p>In this article, we learnt how to create a multi-block plugin, how to extract shared code into packages, and how to manage the complexity of dealing with many blocks and packages.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>When creating a plugin shipping one or more blocks for the WordPress editor, what is the best way to organize the plugin as to make its different components reusable? The block directory (launched in WordPress 5.5) enables to install a block while writing a post in the WordPress editor. This feature might persuade plugin developers [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":5865,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[4,145,12,59],"tags":[25,146,87,90,88],"jetpack_featured_media_url":"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/11\/wordpress-plugin-with-blocks.png","jetpack_publicize_connections":[],"jetpack_shortlink":"https:\/\/wp.me\/p7FQPL-1ww","jetpack-related-posts":[],"jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/posts\/5860"}],"collection":[{"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/comments?post=5860"}],"version-history":[{"count":1,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/posts\/5860\/revisions"}],"predecessor-version":[{"id":5866,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/posts\/5860\/revisions\/5866"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/media\/5865"}],"wp:attachment":[{"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/media?parent=5860"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/categories?post=5860"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/tags?post=5860"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}