shopware/frontends - nuxt-module

Nuxt module that allows you to set up a Nuxt 3 project with Shopware Frontends. It provides the composables and api-client packages.

If you want to use these packages with a different Vue.js framework, see the guide for using Shopware Frontends in a custom project.

Features

• Business logic covered by Composables package. Registering all composable functions globally. See the reference.
• Shopware context shared in Nuxt application.
• Configured API Client package.

Setup

Install npm package:

# Using pnpm
pnpm add -D @shopware/nuxt-module

# Using yarn
yarn add --dev @shopware/nuxt-module

# Using npm
npm i @shopware/nuxt-module --save-dev

Then, register the module by editing nuxt.config.js or (.ts) file (by extending modules array):

/* nuxt.config.ts */

export default defineNuxtConfig({
  /* ... */
  modules: [, /* ... */ "@shopware/nuxt-module"],
  // set the module config
  shopware: {
    // connect to your Shopware 6 API instance
    endpoint: "https://demo-frontends.shopware.store",
    accessToken: "SWSCBHFSNTVMAWNZDNFKSHLAYW",
  },
  // or directly in the runtime config
  // this config will override the base one
  runtimeConfig: {
    public: {
      shopware: {
        endpoint: "https://demo-frontends.shopware.store",
        accessToken: "SWSCBHFSNTVMAWNZDNFKSHLAYW",
      },
    },
  },
});

Set up your own API instance under shopware key or by extending public runtimeConfiguration in the same file. The nuxt module (and vue plugin) will use those values (runtimeConfig will always override the base ones).

Basic usage

Now you can use any composable function you need without extra import:

<script setup>
  const { login } = useUser();
  const { refreshSessionContext } = useSessionContext();
  refreshSessionContext();
</script>

The information about the session is kept in a cookie (sw-context-token) and used in every request made by any composable or directly, invoked by api instance:

<script setup>
  const { apiClient } = useShopwareContext();
  const apiResponse = await apiClient.invoke(/** params omitted */);
</script>

TypeScript support

All composable functions are fully typed with TypeScript and they are registed globally in Nuxt.js application, so the type hinting will help you to work with all of them.

📦 Advanced packaging

Internally, the module uses API Client and Composables packages, configured together to make everything working well. If you need to check how it's working on a different version of one of them, install a package locally in your project (to be installed and available in project's package.json file), then the Nuxt module will use yours. Keep in mind that the different configuration may lead to unexpected behavior.

API Default Headers

You can use Nuxt config to set the default API call headers. More about Nuxt configuration can be found HERE.

NOTE: By default, the values in runtimeConfig are only available on the server-side. However, keys within runtimeConfig.public are also accessible on the client-side. MORE

{
  "runtimeConfig": {
    "public": {
      "apiClientConfig": {
        "headers": {
          "global-heder-example": "global-header-example-value"
        }
      }
    },
    "apiClientConfig": {
      "headers": {
        "ssr-heder-example": "ssr-header-example-value"
      }
    }
  }
}

Register custom API types (tailored for your Shopware instance)

To use custom API types generated by the api-gen package, create a shopware.d.ts file in your project and register the types for the #shopware module. This enables type-safe usage of your custom API types throughout your Nuxt application.

Example of using a local type definitions:

// shopware.d.ts
declare module "#shopware" {
  import type { createAPIClient } from "@shopware/api-client";

  // Use default Shopware types:
  // export type operations =
  //  import("@shopware/api-client/store-api-types").operations;
  // export type Schemas =
  // import("@shopware/api-client/store-api-types").components["schemas"];

  // Or use your locally generated types (placed in ./api-types folder):
  export type operations = import("./api-types/storeApiTypes").operations;
  export type Schemas =
    import("./api-types/storeApiTypes").components["schemas"];

  // Export your own Api Client definition:
  export type ApiClient = ReturnType<typeof createAPIClient<operations>>;
}

Import your custom types from local files and export them as shown above. This approach keeps your types local, allows merging or overriding defaults, and ensures full type safety for API operations and schemas.

Apply custom types for @shopware/api-client

The API Client instance is aware of your custom API types thanks to declaring #shopware module from the step above. So now, whenever apiClient instance is used, the proper types are registered.

Links

• 📘 Documentation

• 📦 API Gen - Types Generator for Shopware 6 OpenAPI Schema

• 📦 API Client - REST API Client for Shopware 6

• 👥 Community (#composable-frontend)

Changelog

Full changelog for stable version is available here

Latest changes: 1.5.0

Minor Changes

• #2473 22611e5 Thanks @mkucmus! - Add an opt-in cacheableReads flag that routes anonymous Store API reads through their cacheable GET variants instead of POST. Criteria is compressed into the _criteria query param via encodeForQuery from @shopware/api-client/helpers, which lets CDNs / reverse proxies / the browser cache the responses.

  Disabled by default — fully backwards compatible. Enable it in nuxt.config (shopware: { cacheableReads: true }) or via createShopwareContext(app, { cacheableReads: true }) for non-Nuxt setups. It is surfaced on the Shopware context and read by the affected composables; public composable signatures are unchanged.

  Affected composables: useNavigation, useNavigationSearch, useCountries, useUser (country + salutation lookups), useSalutations, useInternationalization, useProductConfigurator, useProductSearch, and useCategorySearch.advancedSearch.

  useListing (product-listing), single-category useCategorySearch.search, and useLandingSearch remain POST for now: the generated Store API schema does not type _criteria on those GET routes (a Shopware OpenAPI gap). The backend does honor _criteria on product-listing GET at runtime, so that one can be migrated later once the types are augmented.

Patch Changes

• #2488 c56b89e Thanks @mkucmus! - Register the #shopware types in every TypeScript context (app, server/nitro, node, shared) instead of only the app one. This fixes Cannot find module '#shopware' in server-side code (e.g. server/ routes and API builders) when a project uses the Nuxt 4 project-references tsconfig.json layout. Projects that ship their own shopware.d.ts are referenced in place so their relative imports keep resolving.

• Updated dependencies [8be060d, 5678fb0, 22611e5]:

  • @shopware/composables@1.12.0