WooCommerce Blocks Merging into the WooCommerce Monorepo

With the aim to streamline our development process and enhance collaboration across our community, we will be merging the WooCommerce Blocks plugin into the WooCommerce monorepo. 


You may recall our merger of WooCommerce Admin into the monorepo in March 2022. Since then, we’ve been hard at work iterating and implementing improvements to fully realize the benefits of a monorepo. This includes the introduction of tools, automations, and additional plugins such as the Beta Tester and the new WooCommerce Docs plugin meant to support our initiative to centralize docs. We’ve also initiated a push to make the monorepo the central source of truth for all developer documentation. Given the success of the previous merge, we are now ready to take the next step by merging WooCommerce Blocks into WooCommerce Core.

What’s Changing

  • Folder structure: The WooCommerce Blocks plugin will be integrated directly into WooCommerce Core with its PHP code in the /plugins/woocommerce/src folder and the Javascript in the /plugins/woocommerce-blocks folder.
  • Assets: In the case of assets such as JavaScript and CSS in the WooCommerce Blocks Plugin, the build output will be moving. Currently, built assets for WooCommerce Blocks are shipped in packages/woocommerce-blocks; after the merge, they will be shipped in assets/client/blocks. This should not pose any change for standard development processes. 
  • Release cadence: WooCommerce Blocks Plugin was previously released every two weeks. After the merge, all updates for WooCommerce Blocks will be shipped as part of WooCommerce releases. Consumers of WooCommerce itself should not experience any changes in their day-to-day interactions. If you want a sneak peek at what is coming down the pipeline for WooCommerce Plugin, you can always check out the Beta Tester Plugin for WooCommerce.

Does this change affect me?

I am a developer, shop manager, or merchant who uses the WooCommerce plugin.

No, this change should not affect you. Prior to this change, the WooCommerce Blocks plugin was already being shipped with the WooCommerce monorepo releases, so it is unlikely that you will perceive any changes. 

I am a user of the WooCommerce Blocks plugin

There will no longer be separate releases of the WooCommerce Blocks plugin. This will impact the frequency of Blocks related updates you are used to receiving, since you will only receive updates via WooCommerce. However, we are looking at ways to expand the cadence of releases for the Beta Tester Plugin.

I am a contributor to the WooCommerce Block plugin

Yes, this change will affect you. You will now need to follow the contribution instructions for the WooCommerce monorepo. The commands and setup may differ from what you are used to in the WooCommerce Blocks plugin. We’ve appreciated all the contributions, feedback and discussions folks have provided in the Woo Blocks repository. Open issues and discussions will be transferred to the monorepo using labels you are familiar with (for easier discovery). As a benefit, you will no longer need to wonder about where to go to contribute to Woo Blocks efforts and issue reporting is more streamlined.

Rollout Date

We’re targeting December 8th, 2023 for the merge of the folders. However, this change won’t be reflected in the releases until the release of WC 8.5 on Jan 9, 2024.

Monorepo Developer Experience Improvements

To ensure a smooth transition, we’re implementing several quality-of-life improvements as prerequisites to the merge:

  • Replacing Turborepo: Exploring alternatives to Turborepo to enhance CI performance and improve local development experiences.
  • Minimizing Unnecessary Workflow Executions: Refactoring checks to run minimally, reducing wait times for developers.
  • Deprecating Legacy E2E Packages: Addressing performance issues by deprecating legacy Puppeteer packages in the monorepo.
  • Optimizing Workflows: Implementing small tasks to optimize workflow performance, including sharding E2E tests.
  • Deprecating Stand-alone Blocks Plugin & Merging into Core: Executing the merge using the monorepo-merge utility and transferring open issues, discussions and pull requests appropriately.


We welcome feedback from the community. Your insights and suggestions are invaluable as we strive to make this transition seamless and beneficial for everyone involved.

Reach out to us in the comments below or in WooCommerce Community Slack if you have any questions. We will be providing additional support monitoring in the #monorepo channel from the merge date to the release.

4 responses to “WooCommerce Blocks Merging into the WooCommerce Monorepo”

  1. Is there any standard filter or method to remove WooCommerce blocks from loading assets on the frontend.

    We’re maintaining heavily customised sites that do not use the Gutenberg editor, and don’t need these frontend scripts adding overhead.

    1. Thanks for the report, @addedlovely! WooCommerce Blocks only enqueues assets when blocks are rendered on the page, that means that if you are not using any WooCommerce Blocks in your store, you don’t need to do anything.

      The scripts you are seeing, seem to be related to a new feature that was included in WooCommerce 8.5 named ‘Order Attribution’. You can read more about it in the WooCommerce 8.5.0 release post:


      Our team is currently investigating if we can reduce the scripts loaded in the frontend for this feature to work:


      In the meanwhile, you can disable it from WooCommerce > Settings > Advanced > Order Attribution.

      Hope that helps! Please, let us know if that doesn’t work or you experience any other issues.

      1. Hey Albert,

        Thanks for the reply!

        Seems another similar thread was marked resolved as a non issue. Hope the relationship between store performance / loading time and conversion rate is not being overlooked.

        The introduction of a theme support to disable frontend block related code would be useful for legacy themes moving forward, and presumably would simplify the dev flow for future releases.



        1. Seems another similar thread was marked resolved as a non issue.

          Thanks for pointing it out, I just left a comment in that issue linking to the new one.

          The introduction of a theme support to disable frontend block related code would be useful for legacy themes moving forward, and presumably would simplify the dev flow for future releases.

          I understand your concern. This specific feature is available in classic and block themes, though, as it allows having some data about the origin of the orders.

          We allow store owners to disable the feature if they don’t want it or they have a different system to track this kind of data. I think this feature is not something that should be enabled/disabled at the theme level but more at the store level.

Leave a Reply

Your email address will not be published. Required fields are marked *