woocommerce/plugins/woocommerce-blocks/docs/contributors/javascript-build-system.md

JavaScript Build System

Table of contents

• Environment variables
• Babel
• External scripts
• Aliases
• Styling
• Relevant files

WooCommerce Blocks uses Webpack to build the files that will be consumed by browsers. There are several different Webpack configs in order to build files for different contexts of the plugin. They can all be found in webpack.config.js, but this is a quick summary:

• CoreConfig: config for shared libraries like settings, blocks data or some HOCs and context.
• MainConfig: config that builds the JS files used by blocks in the editor and is responsible for registering the blocks in Gutenberg.
• FrontendConfig: config that builds the JS files used by blocks in the store frontend.
• PaymentsConfig: config that builds the JS files used by payment methods in the Cart and Checkout blocks.
• ExtensionsConfig: config that builds extension integrations.
• StylingConfig: config that builds CSS files. You can read more about it in the page CSS build system.

Details on each config can be found in webpack-configs.js. Entry points are declared in webpack-entries.js.

Environment variables

Different builds are generated depending on the variable NODE_ENV. It can have two values: production or development. Production builds include tree-shaking, minification and other performance enhancements, while development builds are focused on development and include source maps. You can read more about environment variables in Webpack docs.

Babel

Most of our code is transpiled by Babel. This allows us to use the latest JavaScript technologies without affecting browser support.

Some of the Babel plugins we use can be found in webpack-configs.js.

External scripts

Several scripts are loaded as externals. That means that they can be imported in WooCommerce Blocks as any other package, but instead of being bundled in our built files, they are loaded from an external file provided by WordPress (or Gutenberg, if enabled).

@wordpress/dependency-extraction-webpack-plugin is used to automatize dependency extraction for common WP scripts.

In practice, that means the dependency version is:

• deterministic when running WooCommerce Blocks in isolation (e.g. unit tests). In this case, the dependency will have a version as stated in package.json,
• non-deterministic when run in the WordPress ecosystem. Depending on the WordPress or Gutenberg version the user has installed, the version of external dependencies may also vary.

@wordpress/dependency-extraction-webpack-plugin script is applied to each of the build processes: Core, Main, Frontend, Payments, Extensions.

wordpress-components and wordpress-components-slotfill alias

We have an alias to the 14.2.0 version of @wordpress/components called wordpress-components. This alias was used to import a limited set of components in front-end components. This alias is deprecated and should no longer be used. When the FormTokenField component is removed from the codebase, the alias will be removed as well.

We also have one other alias wordpress-components-slotfill which is used to import the SlotFill and Fill components from @wordpress/components. This alias should not be used to import any other dependencies from @wordpress/components. Note that it is tree-shaken so should only bundle the small amount of code directly needed to support slot fill functionality.

If you need to build front-end components in future, you should use Ariakit to build them. See examples like the Button component for how to build components using Ariakit.

Aliases

There are several aliases for internal imports which make importing files across the file tree easier. Instead of having to write a long relative path, they allow writing an alias:

-import { useStoreCartCoupons } from '../../../../base/hooks';
+import { useStoreCartCoupons } from '@woocommerce/base-context/hooks';

Aliases also ease refactors because imports no longer depend on the exact location of the file.

All available aliases can be found in webpack-helpers.js.

Styling

CSS builds follow a separate path from JS builds, more details can be found in the CSS build system.

Relevant files

Webpack config is split between several files:

• webpack.config.js: Top level webpack config.
• bin/webpack-configs.js: Code for generating each build config. This most closely resembles a classic webpack config - if you're looking for something, start here.
• bin/webpack-entries.js: Code for generating webpack entry definitions and mapping source files to entry points. If you're adding a new block or module to the build, start here.
• bin/webpack-helpers.js: Includes utils to load external code at run time, e.g. some dependencies from Woo and WordPress core.

---

We're hiring! Come work with us!

🐞 Found a mistake, or have a suggestion? Leave feedback about this document here.