Shopware Frontends
Shopware Frontends is a collection of NPM packages for Vue.js that enable building a fully custom storefront for Shopware 6 using Nuxt. It includes an API client, CMS components, composables for common shop logic, TypeScript types generated from the Store API OpenAPI spec, and a Nuxt module that ties it all together.
Rather than a ready-made theme, Shopware Frontends is a toolkit. You start from a blank Nuxt application and build the storefront from the ground up, using Shopware Frontends packages as building blocks. The Shopware team provides a demo store as a reference implementation, but explicitly notes that it is not production-ready.
Our experience working with Shopware Frontends has been largely positive. The provided composables are the standout feature—they abstract away API calls and state management for core shop concepts like the cart, product listings, and checkout, letting frontend developers focus on UI without having to deeply understand the Shopware API. The CMS components are well-typed and straightforward to add to a page, and overriding them is simple as long as the component's props and events remain unchanged.
That said, there are rough edges. Some composables are not production-quality—for example, useProductAssociations
had options that were accepted but had no effect because the processing code was commented out, and it lacked support
for fetching SEO URLs alongside associations. We ended up rewriting it ourselves. The TypeScript type generation tool
(@shopware/api-gen) is useful but incomplete: custom fields defined in Shopware are not included in the generated
types, requiring developers to coerce types or disable type checking at every usage site.
A few other limitations are worth noting.
Plugin compatibility Shopware plugins typically bundle frontend code targeting the default Twig storefront. With a standalone Nuxt storefront, only the backend part of a plugin is usable, meaning plugin frontend features must be reimplemented from scratch.
Performance requires discipline With composables abstracting API calls, it's easy to accidentally over-fetch or trigger redundant requests. Regular performance audits are necessary.
SSR-related bugs Nuxt runs application code in two modes: server-side rendering and client-side. The two can behave differently, and it is easy to introduce bugs that only manifest in one of them. Proper testing of both execution paths is essential. This is not specific to Shopware Frontends but is inherent to any Nuxt project, and worth keeping in mind.
The main benefit of Shopware Frontends is flexibility. Teams that are already comfortable with Vue and Nuxt can build highly customized, interactive storefronts without needing deep PHP or Shopware expertise on the frontend side. The architecture also lends itself well to integrating a headless CMS—in our experience, fitting one into a Nuxt-based storefront was noticeably more straightforward than it would have been with the standard Shopware storefront.
However, this flexibility comes at a cost. Every page and every standard eCommerce feature must be explicitly implemented, which requires a solid understanding of eCommerce flows and rigorous testing of critical paths like checkout. For smaller teams or projects with standard requirements, the upfront investment may outweigh the benefits over simply extending the default Twig-based storefront.
We recommend Shopware Frontends for projects that need a high degree of storefront customization and have teams experienced with modern frontend development. For more standard shop setups, the default Shopware storefront remains the pragmatic choice.