# WooCommerce Monorepo: What the GitHub Repository Actually Gives You

> The woocommerce/woocommerce repository is the development home of the WooCommerce plugin, not a storefront installer. Here is what its structure, build scripts and licence mean for developers deciding whether to work from source.

**woocommerce/woocommerce** — A customizable, open-source ecommerce platform built on WordPress. Build any commerce solution you can imagine.

- Repository: https://github.com/woocommerce/woocommerce
- Website: https://woocommerce.com
- Stars: 10,535 · Forks: 10,667
- Language: PHP
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/woocommerce-woocommerce

## Who the WooCommerce monorepo is actually for

WooCommerce is a WordPress plugin that turns a WordPress install into an online store. This repository is not that plugin as a downloadable zip. It is the monorepo where the plugin, the PHP and JavaScript packages the community consumes, and the internal tooling are developed together. The README is explicit about the audience: you can browse the source, look at open issues, contribute code, and keep track of ongoing development. That is a contributor-facing description, not a merchant-facing one.

The practical split matters. If you want to sell things, you install WooCommerce from the WordPress plugin directory or from woocommerce.com, and you never touch this repository. If you want to change how WooCommerce behaves at the code level, fix a bug in core, work on a package such as a JavaScript library under packages/js, or add a tool under tools, this is the only place where that work happens. The repository also states plainly that it is not suitable for support and that issue tracker requests for support will be closed. Anyone arriving here with a checkout problem is in the wrong building.

## How the monorepo is laid out and what the build actually does

The top level separates concerns. plugins/woocommerce holds the core plugin. packages/ holds PHP and JavaScript libraries, some prefixed internal- to mark them as private dependencies rather than things the community is expected to consume directly. tools/ holds utilities and scripts for the monorepo itself, and the README points to tools/README.md for how the monorepo works. Each plugin, package and tool carries its own package.json with its own dependencies and scripts, and most also carry a project-specific README.

The root package.json is the orchestrator. Its build script runs pnpm -r across the workspace, filtering for scripts whose names match build:project:.*, with workspace concurrency set to Infinity and streaming output. So a single pnpm build fans out into every project that declares a build:project: script, and the root does not know what those projects do. That is the standard workspace pattern, and it means build failures are reported per project rather than centrally. There are also targeted entry points: wc:build filters to @woocommerce/plugin-woocommerce, and wc:build:admin, wc:build:blocks and wc:build:classic-assets narrow further to the admin client, the blocks client and the classic assets. If you are only touching the admin UI, running the filtered script avoids rebuilding everything.

The dependency graph is managed by PNPM, and the repository enforces that choice: the preinstall script runs npx only-allow pnpm, so npm or Yarn installs are rejected before they start. PHP dependencies go through Composer, which is why the README lists both toolchains as prerequisites.

## Installing the WooCommerce monorepo and running a first build

The README lists four prerequisites: Node.js, PNPM, PHP 7.4 or higher, and Composer. You do not need to install a matching Node version by hand. PNPM reads the version pinned in pnpm-workspace.yaml under useNodeVersion, mirrored in .nvmrc, and installs and uses that version for every script it runs. The root package.json pins packageManager to pnpm@10.33.0 and declares engines.node as ^24.15.0, so if you do install Node yourself, that is the range the repository expects. A Node version manager is described as optional but handy.

The README also states that a POSIX-compliant operating system such as Linux or macOS is assumed, and that Windows users should work through WSL. That is a real constraint, not a footnote: the scripts and tooling assume a POSIX shell.

Once the prerequisites are in place, the README gives two commands to prepare all build outputs needed for development. The first installs PHP and Composer dependencies across every plugin, package and tool in the workspace; the second builds them.

```bash
pnpm install --frozen-lockfile
pnpm build
```

The --frozen-lockfile flag means PNPM will not rewrite pnpm-lock.yaml; if the lockfile and the manifests disagree, the install fails rather than silently resolving. Expect a long first run, because it spans the whole workspace. If you only want the core plugin built, the root package.json exposes a filtered shortcut instead.

```bash
pnpm wc:build
```

That runs the build script inside the @woocommerce/plugin-woocommerce workspace only. For a local WordPress environment, the root package.json also exposes wc:env and wc:env:restart, which delegate to an env:dev and env:restart script in the same workspace. The README does not describe what those scripts provision, so check plugins/woocommerce/package.json before assuming they give you a working store. When you are done, pnpm clean removes node_modules directories and vendor directories across packages and plugins, then prunes the PNPM store; pnpm clean:build removes build caches and build output directories and cleans generated assets under plugins/woocommerce/assets.

## Where the WooCommerce monorepo workflow breaks down

The most obvious failure mode is using the wrong install path. Nothing in this repository produces a merchant-ready store. The README directs support to a self-help guide, the WooCommerce.com support portal for customers who bought themes or extensions, the wp.org community forum, and a Facebook group. If your goal is a working shop, the monorepo is the wrong tool and the plugin directory is the right one.

The second is platform. The POSIX assumption plus WSL guidance for Windows means native Windows contributors are working against the grain of the tooling. That is a documented boundary, not a bug, but it decides some teams' setups before they start.

The third is scope creep in the build. pnpm build runs every build:project: script in the workspace with concurrency set to Infinity. On a small machine, that is a lot of parallel work, and the root build has no built-in way to skip a project you do not care about. The filtered wc:* scripts are the workaround, and they exist precisely because the full build is heavy. If you are bisecting a bug in one package, running the whole monorepo build each time is wasted time.

The fourth is versioning discipline. The repository ships a nightly release entry dated 2020-04-28 alongside current releases, and pre-release tags such as 11.2.0-beta.1 sit next to stable tags such as 11.1.1. If you build from trunk, you are building unreleased code. The README does not document a rollback procedure for a bad build, so plan on using git history yourself rather than expecting a supported revert path.

## WooCommerce from source versus installing the plugin

The real alternative to this repository is the packaged plugin. Installing WooCommerce from the WordPress plugin directory or from a WooCommerce.com download gives you a versioned artifact that WordPress can activate, update and roll back through its own mechanisms. The monorepo gives you source, a workspace of packages, and a build pipeline that you run yourself. The difference in approach is not a matter of preference: the packaged plugin is a product, and the monorepo is a factory.

A second comparison people reach for is WooCommerce against a hosted platform. That is a different axis entirely, about where your store's data and runtime live, and the repository tells you nothing about it. What the repository does tell you is that WooCommerce core is a WordPress plugin, so your store inherits WordPress's hosting model, its plugin ecosystem and its update cycle. If you want to change that model, you are changing WordPress, not just WooCommerce.

Within the repository itself, the closest thing to an alternative workflow is the filtered build. Running pnpm wc:build instead of pnpm build is the difference between compiling one plugin and compiling everything the workspace declares. Both are documented paths; picking the wrong one is a matter of patience, not correctness.

## Licence and the cost of staying current

The repository's package.json declares license as GPL-2.0-or-later, and the top level contains a license.txt file. The repository metadata shown here reports the licence as NOASSERTION, which means the platform's automated detection could not classify it. Those two signals disagree, and the practical consequence is that you should read license.txt and the licence headers in the specific files you intend to reuse rather than trusting a single string. This is not legal advice; if you are redistributing WooCommerce code inside a commercial product, have someone qualified read the actual licence text.

The maintenance cost is the build surface. Node, PNPM, PHP and Composer all have to stay in the ranges the workspace declares, and the pinned Node version in pnpm-workspace.yaml is the one PNPM will install for you. Root scripts such as sync-dependencies run pnpm exec syncpack fix to reconcile dependency versions across the workspace, which tells you version drift between packages is an expected, recurring chore rather than a one-time setup step. The repository's last push was on 2026-09-21, so trunk moves; if you build from it, you are tracking a moving target rather than a frozen release.

## Conclusion

Adopt the monorepo if you are changing WooCommerce core, a bundled package or a tool in tools/, and you are comfortable with PNPM workspaces, Composer and a POSIX shell. Do not adopt it if you want a running shop: the README states the repository is not suitable for support, and merchants should install the plugin from the WordPress plugin directory or a WooCommerce.com download instead. Before you spend a day on setup, verify three things on your own machine: that pnpm install --frozen-lockfile completes against the pinned Node version, that pnpm build produces the plugin build outputs your workflow needs, and that the licence file ships with whatever you redistribute, because the repository's own metadata and its package.json do not agree on the licence string.

## FAQ

### What is WooCommerce used for?

WooCommerce is a WordPress plugin that turns a WordPress site into an online store. This repository is the monorepo where that plugin, its PHP and JavaScript packages and its internal tooling are developed, so it is aimed at contributors rather than at merchants setting up a shop.

### Is selling on WooCommerce free?

The repository does not discuss pricing, so nothing here settles what a store costs to run. What it does say is that the plugin is open source and that premium support is a separate portal for customers who have purchased themes or extensions.

### How do I install WooCommerce on WordPress?

This repository does not give merchant installation steps. The README points to the WordPress plugin directory and to WooCommerce.com for support, and states that the repository is not suitable for support requests. The install instructions here are for developers building from source.

### How do I use the WooCommerce REST API?

The README does not document the REST API. The repository does contain packages/php and packages/js directories, so API-related code may live there, but the README gives no endpoint list, authentication scheme or usage example.

## Sources

- [Issues](https://github.com/woocommerce/woocommerce/issues)
- [Project website](https://woocommerce.com)
- [README](https://github.com/woocommerce/woocommerce/blob/trunk/README.md)
- [Releases](https://github.com/woocommerce/woocommerce/releases)
- [woocommerce/woocommerce on GitHub](https://github.com/woocommerce/woocommerce)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/woocommerce-woocommerce