@scayle/storefront-nuxt 8.61.1 → 8.61.2

package/CHANGELOG.md

@@ -1,5 +1,26 @@
 # @scayle/storefront-nuxt
 
+## 8.61.2
+
+### Patch Changes
+
+- Improved build-time loading of custom RPC modules when generating the
+  `#virtual/rpcHttpMethods` manifest so Nuxt string aliases (for example `#shared`) resolve the same way
+  as in app code during HTTP verb inference.
+  - Resolved aliases from `@nuxt/kit` `resolvePath` (including virtual templates)
+    are passed to Jiti together with an app-root parent URL so imports inside `rpcMethods` match dev
+    behavior.
+  - If a module still cannot be resolved or imported, those methods continue to default to `POST` with a
+    logged warning.
+
+- Added dependency `jiti@^2.6.1`
+
+**Dependencies**
+
+**@scayle/storefront-core v8.61.2**
+
+- No changes in this release.
+
 ## 8.61.1
 
 ### Patch Changes
@@ -23,13 +44,13 @@
 
   ```ts
   // Safe reads — eligible for CDN / browser caching
-  export const getNavigation = defineRpcHandler(handler, { method: "GET" });
+  export const getNavigation = defineRpcHandler(handler, { method: 'GET' })
 
   // Mutations
-  export const updateBasketItem = defineRpcHandler(handler, { method: "PUT" });
+  export const updateBasketItem = defineRpcHandler(handler, { method: 'PUT' })
   export const deleteWishlistItem = defineRpcHandler(handler, {
-    method: "DELETE",
-  });
+    method: 'DELETE',
+  })
   ```
 
   RPCs returning user-specific data (basket, wishlist, tokens) should stay on `POST` to prevent unintended caching.
@@ -43,29 +64,28 @@
 **@scayle/storefront-core v8.61.0**
 
 - Minor
-
   - **[RPC]** `defineRpcHandler` now accepts an optional `method` option (`'GET' | 'POST' | 'PUT' | 'DELETE'`) to declare the HTTP method for the handler. Defaults to `'POST'`, so existing handlers behave exactly as before. Updated built-in RPC methods to use `GET` for safe, cacheable reads and `PUT`/`POST`/`DELETE` for mutations, enabling CDN and browser caching for public data fetches.
 
   User- and session-specific RPCs (`getBasket`, `getUser`, `fetchUser`, `getWishlist`, `getAccessToken`, `getCheckoutToken`, `getOrderById`, `getCheckoutDataByCbd`, `getShopUserAddress`) intentionally stay on `POST` so their responses are never eligible for CDN or browser caching.
 
   ```ts
-  import { defineRpcHandler, type RpcContext } from "@scayle/storefront-core";
+  import { defineRpcHandler, type RpcContext } from '@scayle/storefront-core'
 
   // Safe, public read — eligible for CDN/browser caching
   export const getNavigation = defineRpcHandler(
     async (context: RpcContext) => {
       /* ... */
     },
-    { method: "GET" }
-  );
+    { method: 'GET' },
+  )
 
   // User-specific / Mutation — uses POST to prevent cache leakage
   export const getBasket = defineRpcHandler(
     async (context: RpcContext) => {
       /* ... */
-    }
+    },
     // method defaults to 'POST'
-  );
+  )
   ```
 
 - Patch
@@ -97,7 +117,6 @@
 **@scayle/storefront-core v8.60.0**
 
 - Minor
-
   - All packages now require Node.js 22 or later, in line with the current Node.js LTS release schedule. See the [Node.js release schedule](https://nodejs.org/en/about/previous-releases#release-schedule) for details.
 
   If your project is still running an older Node.js version, now is a good time to upgrade to Node.js 22 at minimum, or ideally Node.js 24, for the latest security patches and stability improvements.
@@ -151,7 +170,6 @@
 **@scayle/storefront-core v8.59.4**
 
 - Patch
-
   - Fixed error handling in `oauthRegister` and other OAuth-related RPC methods to properly propagate HTTP status codes like 409 Conflict instead of converting them to 500 Internal Server Error.
 
   The `convertErrorForRpcCall` function now correctly handles `OAuthRequestError` instances that wrap `FetchError` objects. Previously, when OAuth API errors occurred (such as attempting to register with an existing email), the error handling only checked for direct `FetchError` instances, causing wrapped errors to fall through to a generic 500 error response. Now the function extracts the underlying `FetchError` from `OAuthRequestError` instances, ensuring that the correct HTTP status codes are returned to the frontend.
@@ -179,7 +197,6 @@
 **@scayle/storefront-core v8.59.2**
 
 - Patch
-
   - Deprecated the `slugify` and `getProductPath` functions in `productHelpers.ts` due to compatibility issues with Nuxt 4.
 
   To maintain compatibility with Nuxt 4, these functions have been deprecated. Developers should migrate to using `useRouteHelpers().slugify()` instead. Additionally, the `slugify` package must be added as a direct dependency in your Storefront Application.
@@ -187,33 +204,33 @@
   **Migration:**
 
   ```ts
-  import baseSlugify from "slugify";
+  import baseSlugify from 'slugify'
 
   const slugify = (url: string | undefined): string => {
-    return baseSlugify(url ?? "", {
+    return baseSlugify(url ?? '', {
       lower: true,
       remove: /[*+~.()'"!:@/#?]/g,
-    });
-  };
+    })
+  }
 
-  const localePath = useLocalePath();
+  const localePath = useLocalePath()
 
   const getProductDetailRoute = (
     id: number,
     name?: string,
-    locale?: Locale
+    locale?: Locale,
   ): string => {
     return localePath(
       {
-        name: "p-productName-id",
+        name: 'p-productName-id',
         params: {
           productName: slugify(name),
           id: `${id}`,
         },
       },
-      locale
-    );
-  };
+      locale,
+    )
+  }
   ```
 
 ## 8.59.1
@@ -228,7 +245,6 @@
 **@scayle/storefront-core v8.59.1**
 
 - Patch
-
   - Fixed import compatibility issue with the `slugify` package in `productHelpers.ts` to support both ESM and CommonJS module formats.
 
   The import was changed from a default import to a namespace import with a fallback, ensuring the `baseSlugify` function works correctly across different module systems and build configurations.
@@ -252,7 +268,6 @@
 
 - Introduced support for Nuxt 4 while maintaining full backward compatibility with Nuxt 3.
   This enables consumers to migrate to Nuxt 4 ahead of the Nuxt 3 end of support on 31 Jan 2026.
-
   - **Version Requirements:**
     - Nuxt 3: `v3.13.0+`
     - Nuxt 4: `v4.2.0+`
@@ -336,11 +351,9 @@
 **@scayle/storefront-core v8.57.0**
 
 - Minor
-
   - **\[Navigation\]** Exported Navigation V2 API types to provide TypeScript support for the new navigation endpoints.
 
   The following types are now available from `@scayle/storefront-core`:
-
   - `GetNavigationV2Parameters` - Parameters for fetching navigation trees via the V2 API
   - `NavigationV2AllEndpointResponseData` - Response type for fetching all navigation trees
   - `NavigationV2ByReferenceEndpointResponseData` - Response type for fetching a navigation tree by reference key
@@ -356,7 +369,6 @@
   The `RpcContext` now exposes a `sessionCustomData` property to read custom session data and an `updateSessionCustomData` method to update it.
   The `sessionCustomData` property may be `undefined` when no session exists or when no custom data has been set.
   The `SessionCustomData` interface can be augmented with TypeScript module augmentation to provide type safety for custom session properties.
-
   - **Type Augmentation Example:**
 
         ```ts
@@ -374,39 +386,39 @@
 
     ```ts
     // server/plugins/session-plugin.ts
-    import { hasSession } from "@scayle/storefront-nuxt";
-    import { defineNitroPlugin } from "#imports";
+    import { hasSession } from '@scayle/storefront-nuxt'
+    import { defineNitroPlugin } from '#imports'
 
     export default defineNitroPlugin((nitroApp) => {
-      nitroApp.hooks.hook("storefront:afterLogin", async (_data, context) => {
+      nitroApp.hooks.hook('storefront:afterLogin', async (_data, context) => {
         // Check if we actually have a RpcContext with proper session data
         if (!hasSession(context)) {
-          return;
+          return
         }
 
         // Should you have set custom session data already in another hook,
         // it might be necessary to get existing data first.
-        const sessionCustomData = context.sessionCustomData;
+        const sessionCustomData = context.sessionCustomData
 
         // The update functions overrides the customData object on a session.
         // Should you have set custom session data already in another hooks,
         // you need to pass it in addition to your new custom session data.
         context.updateSessionCustomData({
           ...sessionCustomData,
-          yourCustomDataKey: "Your Session CustomData Value",
-        });
+          yourCustomDataKey: 'Your Session CustomData Value',
+        })
 
         // Before accessing your session custom data, you might want to use an
         // explicit early return conditional.
         if (!sessionCustomData) {
-          return;
+          return
         }
 
         // Your custom session data can also be accessedd directly via
         // nullish coalescing  depending on your needs.
-        console.log(context.sessionCustomData?.yourCustomDataKey);
-      });
-    });
+        console.log(context.sessionCustomData?.yourCustomDataKey)
+      })
+    })
     ```
 
 ### Patch Changes
@@ -418,7 +430,6 @@
 **@scayle/storefront-core v8.56.0**
 
 - Minor
-
   - Added support for custom session data in the RPC context type definitions.
 
   The `ContextWithSession` interface now includes a `sessionCustomData` property (which may be `undefined`) to read custom session data and an `updateSessionCustomData` method to update it.
@@ -460,26 +471,25 @@
 - Enhanced data fetching composables to support reactive keys, aligning with [Nuxt 3.17 data fetching improvements](https://nuxt.com/blog/v3-17#data-fetching-improvements).
 
   You can now pass a `ref`, `computed`, or getter function as the `key` parameter to `useRpc` and derived composables (like `useProducts`, `useBrand` etc.). When the reactive key changes, the data will automatically re-fetch.
-
   - **Before:** Keys were static strings.
   - **After:** Keys can be reactive, enabling dynamic caching and automatic updates.
 
   ```ts
   // Before
-  const { data } = await useRpc("getProduct", "my-static-product-key", {
+  const { data } = await useRpc('getProduct', 'my-static-product-key', {
     productId: 123,
-  });
+  })
 
   // After
-  const productId = ref(123);
+  const productId = ref(123)
 
   // The key is now reactive. If `productId` changes, the key updates
   // to 'product-456' (for example) and triggers a new fetch.
   const { data } = await useRpc(
-    "getProduct",
+    'getProduct',
     () => `product-${productId.value}`,
-    { productId }
-  );
+    { productId },
+  )
   ```
 
 - Deprecated the `CheckoutEvent` type, which will be removed in the next major version.
@@ -491,22 +501,22 @@
   The type definition remains unchanged, so you can copy it directly:
 
   ```ts
-  import type { ShopUser } from "@scayle/storefront-nuxt";
+  import type { ShopUser } from '@scayle/storefront-nuxt'
 
   export interface CheckoutEvent {
     /** Action. */
-    action?: "authenticated";
+    action?: 'authenticated'
     /** Type. */
-    type?: "tracking";
+    type?: 'tracking'
     /** User. */
-    user: ShopUser;
+    user: ShopUser
     /**
      * The OAuth 2.0 access token for the authenticated user.
      * This token can be used to access protected resources on behalf of the user.
      *
      * @see https://www.rfc-editor.org/rfc/rfc6749
      */
-    accessToken: string;
+    accessToken: string
     /**
      * Details about a specific event within the checkout process.
      * This field is optional and is only used when tracking specific actions
@@ -516,25 +526,25 @@
      */
     event?: {
       /** Event name. */
-      event: "login" | "add_to_cart" | "remove_from_cart";
+      event: 'login' | 'add_to_cart' | 'remove_from_cart'
       /** Event status. */
-      status: "successful" | "error";
-    };
+      status: 'successful' | 'error'
+    }
   }
   ```
 
 - Updated the `StorefrontRuntimeConfig` type to ensure configured `shops` correctly incorporates all extended properties from `AdditionalShopConfig`.
 
   ```ts
-  declare module "@scayle/storefront-nuxt" {
+  declare module '@scayle/storefront-nuxt' {
     // Extend the shop config
     export interface AdditionalShopConfig {
-      extendedProp: string;
+      extendedProp: string
     }
   }
 
   // `extendedProp` is now properly typed
-  useRuntimeConfig().storefront.shops?.[shopId]?.extendedProp;
+  useRuntimeConfig().storefront.shops?.[shopId]?.extendedProp
   ```
 
 **Dependencies**
@@ -554,11 +564,11 @@
   ```ts
   // Before (or when `rpcDefaultLazy: false`)
   // You had to explicitly opt-in to lazy behavior
-  const { data } = useRpc("someMethod", { some: "param" }, { lazy: true });
+  const { data } = useRpc('someMethod', { some: 'param' }, { lazy: true })
 
   // After (when `rpcDefaultLazy: true`)
   // Lazy behavior is now the default
-  const { data } = useRpc("someMethod", { some: "param" });
+  const { data } = useRpc('someMethod', { some: 'param' })
   ```
 
 **Dependencies**
@@ -591,7 +601,6 @@
 **@scayle/storefront-core v8.53.0**
 
 - Minor
-
   - Added support for promotions on order items by introducing the `OrderItemPromotion` interface and extending the `OrderItem` type with an optional `promotions` field.
 
   This enables developers to access promotion information (`id`, `name`, and `version`) directly from order items, improving visibility into which promotions were applied to each item in an order.
@@ -621,7 +630,6 @@
 **@scayle/storefront-core v8.51.0**
 
 - Minor
-
   - Added an email hash (`emailHash`) property to the user object returned by the `fetchUser` RPC method.
 
   The `emailHash` property is automatically included in all user objects returned by the RPCs.
@@ -633,7 +641,6 @@
 ### Minor Changes
 
 - Introduced validation for domain configuration when `shopSelector: 'domain'` is enabled. This ensures that any domain-related misconfigurations are detected early during development. The validation requires the use of `@nuxtjs/i18n` and includes the following checks:
-
   - Ensures every shop has a domain property configured
   - Verifies that domains configured in the shop config are also present in the `@nuxtjs/i18n` configuration
   - Checks that all domains in the i18n configuration are unique (no duplicates)
@@ -661,7 +668,6 @@
 **@scayle/storefront-core v8.49.0**
 
 - Minor
-
   - Exported the `sha256` utility function as part of the public API.
 
   This function provides a convenient way to calculate SHA256 hashes of strings using the Web Crypto API, returning hexadecimal strings.
@@ -670,10 +676,10 @@
   Example:
 
   ```ts
-  import { sha256 } from "@scayle/storefront-core";
+  import { sha256 } from '@scayle/storefront-core'
 
-  const hash = await sha256("hello");
-  console.log(hash); // '2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824'
+  const hash = await sha256('hello')
+  console.log(hash) // '2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824'
   ```
 
 ## 8.48.1
@@ -687,11 +693,9 @@
 **@scayle/storefront-core v8.48.1**
 
 - Patch
-
   - Export `SmartSortingKey` constant containing all predefined smart sorting keys for intelligent product sorting. Smart sorting keys provide advanced sorting algorithms that consider multiple factors like discounts, inventory levels, sales performance, and recency to optimize product listings.
 
   Available keys:
-
   - `SmartSortingKey.SALES_PUSH` - Promotes items with highest discounts and oldest inventory
   - `SmartSortingKey.NEW_ARRIVALS` - Prioritizes recently added products with good availability
   - `SmartSortingKey.BALANCED_OFFERINGS` - Balances recency, availability, discounts, and sales data
@@ -734,7 +738,6 @@
 **@scayle/storefront-core v8.47.0**
 
 - Minor
-
   - Enhanced basket RPC methods to support order custom data functionality.
 
   All basket RPC methods now integrate with the `getOrderCustomData` RPC method to fetch and include order custom data in SAPI requests.
@@ -753,12 +756,11 @@
         customer: {
           groups: context.user?.groups,
         },
-      };
-    });
+      }
+    })
   ```
 
   For further information, please refer to the [Overriding Core RPC Methods](https://scayle.dev/en/core-documentation/storefront-guide/storefront-application/technical-foundation/rpc-methods?sourceText=RPC%2520Methods#overriding-core-rpc-methods).
-
   - Updated all basket RPC methods to pass the customer access token to the SAPI client, enabling the `X-Customer-Token` header for promotion validation.
 
   The customer access token is now automatically included in basket requests when available.
@@ -775,7 +777,6 @@
 **@scayle/storefront-core v8.46.0**
 
 - Minor
-
   - Added `getAttributeValuesByGroupId` function to the `attributeHelpers` helper for retrieving attribute values by their numeric attribute group ID.
 
   This function allows you to retrieve attribute values filtered by a specific attribute group ID, providing a more targeted approach when working with grouped product attributes.
@@ -788,37 +789,36 @@
   #### Looking up by name (existing, now renamed):
 
   ```typescript
-  import { getAttributeValuesByName } from "@scayle/storefront-core";
+  import { getAttributeValuesByName } from '@scayle/storefront-core'
 
   // Single-select attribute
-  const sizes = getAttributeValuesByName(product.attributes, "size");
+  const sizes = getAttributeValuesByName(product.attributes, 'size')
   // Returns: [{ id: 1, label: 'M', value: 'medium' }]
 
   // Multi-select attribute
-  const colors = getAttributeValuesByName(product.attributes, "color");
+  const colors = getAttributeValuesByName(product.attributes, 'color')
   // Returns: [{ id: 1, label: 'Red' }, { id: 2, label: 'Blue' }]
 
   // Non-existent attribute
-  const missing = getAttributeValuesByName(product.attributes, "doesNotExist");
+  const missing = getAttributeValuesByName(product.attributes, 'doesNotExist')
   // Returns: []
   ```
 
   #### Looking up by group ID (new):
 
   ```typescript
-  import { getAttributeValuesByGroupId } from "@scayle/storefront-core";
+  import { getAttributeValuesByGroupId } from '@scayle/storefront-core'
 
   // Look up attribute by its numeric ID from the SCAYLE API
-  const promotionValues = getAttributeValuesByGroupId(product.attributes, 42);
+  const promotionValues = getAttributeValuesByGroupId(product.attributes, 42)
   // Returns: [{ id: 123, label: 'Summer Sale', value: 'summer-2024' }]
 
   // Non-existent attribute group
-  const missing = getAttributeValuesByGroupId(product.attributes, 9999);
+  const missing = getAttributeValuesByGroupId(product.attributes, 9999)
   // Returns: []
   ```
 
   ### When to Use Each Function
-
   - **`getAttributeValuesByName`**: Use when you know the attribute name key (e.g., 'color', 'size'). This is the most common use case in application code.
   - **`getAttributeValuesByGroupId`**: Use when you have the numeric attribute group ID from the SCAYLE API, such as when processing API configurations, handling dynamic attribute mappings, or working with attribute group references.
 
@@ -876,27 +876,27 @@
   // nuxt.config.ts
   export default defineNuxtConfig({
     storefront: {
-      apiBasePath: "/custom-api", // ✅ Configure globally for all shops
+      apiBasePath: '/custom-api', // ✅ Configure globally for all shops
     },
     runtimeConfig: {
       storefront: {
         shops: {
           1001: {
             shopId: 1001,
-            path: "de",
+            path: 'de',
             // ✅ apiBasePath removed from shop config
             // ... other shop config
           },
           1002: {
             shopId: 1002,
-            path: "en",
+            path: 'en',
             // ✅ apiBasePath removed from shop config
             // ... other shop config
           },
         },
       },
     },
-  });
+  })
   ```
 
   Additionally, the types for the Storefront module options and Storefront runtime configuration have been cleaned up to properly reflect which settings can be set at runtime and which cannot. This clarifies the distinction between configuration that is static (set at build/module level) and configuration that is dynamic (set at runtime), improving type safety and developer experience.
@@ -1003,7 +1003,6 @@
 **@scayle/storefront-core v8.43.0**
 
 - Minor
-
   - Added an export of the new promotion type `ComboDealEffect`
 
   This type is also included in the `PromotionEffectType` type and can be used to check if the promotion is of type `ComboDealEffect`.
@@ -1012,10 +1011,10 @@
 
   ```ts
   const isComboDealType = (
-    promotion?: Promotion | null
+    promotion?: Promotion | null,
   ): promotion is Promotion<ComboDealEffect> => {
-    return promotion?.effect?.type === PromotionEffectType.COMBO_DEAL;
-  };
+    return promotion?.effect?.type === PromotionEffectType.COMBO_DEAL
+  }
   ```
 
 ## 8.42.2
@@ -1079,68 +1078,68 @@
   Before:
 
   ```ts
-  const updateBasketItemRpc = useRpcCall("updateBasketItem");
-  const addItemToBasketRpc = useRpcCall("addItemToBasket");
+  const updateBasketItemRpc = useRpcCall('updateBasketItem')
+  const addItemToBasketRpc = useRpcCall('addItemToBasket')
 
   updateBasketItemRpc({
     // ...
-    promotionId: "promotionId",
-    promotionCode: "promotionCode",
-  });
+    promotionId: 'promotionId',
+    promotionCode: 'promotionCode',
+  })
 
   addItemToBasketRpc({
     // ...
-    promotionId: "promotionId",
-    promotionCode: "promotionCode",
-  });
+    promotionId: 'promotionId',
+    promotionCode: 'promotionCode',
+  })
 
   // Or with useBasket composable
 
-  const { addItem } = useBasket();
+  const { addItem } = useBasket()
   addItem({
     // ...
-    promotionId: "promotionId",
-  });
+    promotionId: 'promotionId',
+  })
   ```
 
   After:
 
   ```ts
-  const updateBasketItemRpc = useRpcCall("updateBasketItem");
-  const addItemToBasketRpc = useRpcCall("addItemToBasket");
+  const updateBasketItemRpc = useRpcCall('updateBasketItem')
+  const addItemToBasketRpc = useRpcCall('addItemToBasket')
 
   updateBasketItemRpc({
     // ...
     promotions: [
-      { id: "promotionId", code: "promotionCode" },
+      { id: 'promotionId', code: 'promotionCode' },
       {
-        id: "promotionId2",
+        id: 'promotionId2',
       },
     ],
-  });
+  })
 
   addItemToBasketRpc({
     // ...
     promotions: [
-      { id: "promotionId", code: "promotionCode" },
+      { id: 'promotionId', code: 'promotionCode' },
       {
-        id: "promotionId2",
+        id: 'promotionId2',
       },
     ],
-  });
+  })
 
   // Or for useBasket with composable
 
-  const { addItem } = useBasket();
+  const { addItem } = useBasket()
   addItem({
     // ...
     promotions: [
-      { id: "promotionId", code: "promotionCode" },
+      { id: 'promotionId', code: 'promotionCode' },
       {
-        id: "promotionId2",
+        id: 'promotionId2',
       },
     ],
-  });
+  })
   ```
 
   For more details, see the [Add a variant](https://scayle.dev/en/api-guides/storefront-api/resources/baskets/add-a-variant) and [Update an item](https://scayle.dev/en/api-guides/storefront-api/resources/baskets/update-an-item) guides.
@@ -1152,7 +1151,6 @@
 **@scayle/storefront-core v8.42.0**
 
 - Minor
-
   - Added `promotions` field to `BasketItem` type to support multiple promotions per basket item.
 
   The `promotions` field is an array of `BasketItemPromotion` objects.
@@ -1260,7 +1258,7 @@
   </template>
 
   <script setup lang="ts">
-    const { relativeReductions } = useProductPrice(price);
+    const { relativeReductions } = useProductPrice(price)
   </script>
   ```
 
@@ -1275,7 +1273,7 @@
   </template>
 
   <script setup lang="ts">
-    const { appliedReductions } = useProductPrice(price);
+    const { appliedReductions } = useProductPrice(price)
   </script>
   ```
 
@@ -1413,7 +1411,6 @@
 **@scayle/storefront-core v8.36.0**
 
 - Minor
-
   - Created a new RPC method `getCampaign` to retrieve the first active campaign.
 
   More details can be found in the official SCAYLE Resource Center under [API Guides / Storefront API / Campaigns / List Campaigns](https://scayle.dev/en/api-guides/storefront-api/resources/campaigns/list-campaigns).
@@ -1501,7 +1498,6 @@
 **@scayle/storefront-core v8.33.0**
 
 - Minor
-
   - Added test factories for order and all related types.
 
   It is now possible to build orders with factory functions for testing purposes.
@@ -1541,27 +1537,26 @@
 **@scayle/storefront-core v8.31.0**
 
 - Minor
-
   - Added `minReduction` and `maxReduction` filter parameters to `FetchProductsByCategoryParams.where` and `FetchFiltersParams.where` types, and updated the `getProductsByCategory` and `getFilters` RPC methods to accept and handle these new reduction-based filtering conditions.
 
   ```ts
-  const { data } = useRpc("getFilters", "getFiltersKey", () => ({
+  const { data } = useRpc('getFilters', 'getFiltersKey', () => ({
     where: {
       minReduction: 10,
       maxReduction: 20,
     },
-  }));
+  }))
 
   const { data } = useRpc(
-    "getProductsByCategory",
-    "getProductsByCategoryKey",
+    'getProductsByCategory',
+    'getProductsByCategoryKey',
     () => ({
       where: {
         minReduction: 10,
         maxReduction: 20,
       },
-    })
-  );
+    }),
+  )
   ```
 
 ## 8.30.3
@@ -1606,35 +1601,34 @@
 **@scayle/storefront-core v8.30.0**
 
 - Minor
-
   - Added `defineRpcHandler` utility function that enhances RPC handlers with type-safe metadata for improved registration and invocation of RPC handlers. While defining RPC handlers without this utility remains supported, its usage is recommended and may become mandatory in a future major release.
 
   Existing RPC handlers can be easily migrated to use `defineRpcHandler` by passing the existing handler to `defineRpcHandler`.
 
   ```ts
   export const existingHandlerWithoutParams = async (_context: RpcContext) => {
-    return "existing handler";
-  };
+    return 'existing handler'
+  }
 
   export const existingHandlerWithParams = async (
     { name }: { name: string },
-    _context: RpcContext
+    _context: RpcContext,
   ) => {
-    return name;
-  };
+    return name
+  }
 
   // will become
 
   export const existingHandlerWithoutParams = defineRpcHandler(
     async (_context: RpcContext) => {
-      return "existing handler";
-    }
-  );
+      return 'existing handler'
+    },
+  )
   export const existingHandlerWithParams = defineRpcHandler(
     async ({ name }: { name: string }, _context: RpcContext) => {
-      return name;
-    }
-  );
+      return name
+    },
+  )
   ```
 
 - Patch
@@ -1649,22 +1643,21 @@
 **@scayle/storefront-core v8.29.0**
 
 - Minor
-
   - Added an `includeProductSorting` boolean parameter to all category RPC method endpoints (`getRootCategories`, `getCategoryByPath`, `getCategoriesByPath`, `getCategoryById`, `getCategoryTree`).
     This flag allows consumers to retrieve product sorting data, including the `smartSortingKey` and `customSortingKey` properties.
     Developers can leverage this data to seamlessly apply smart sorting keys on the product listing page by passing those parameters when fetching products.
   - Added an optional `hideEmptyCategories` parameter to `getCategoryTree`. When enabled, the product count for each category is retrieved, and categories (including their children) without any products are removed. Enabling this option may increase response times, especially for large category trees.
 
   ```ts
-  import { rpcMethods } from "@scayle/storefront-core";
+  import { rpcMethods } from '@scayle/storefront-core'
 
-  rpcMethods.getCategoryTree({ hideEmptyCategories: true }, rpcContext);
+  rpcMethods.getCategoryTree({ hideEmptyCategories: true }, rpcContext)
   ```
 
   or
 
   ```ts
-  import { useCategoryTree } from "#storefront/composables";
+  import { useCategoryTree } from '#storefront/composables'
 
   const { data: rootCategories, status } = useCategoryTree(
     {
@@ -1672,8 +1665,8 @@
         hideEmptyCategories: true,
       },
     },
-    "category-navigation-tree"
-  );
+    'category-navigation-tree',
+  )
   ```
 
 ## 8.28.7
@@ -1770,9 +1763,9 @@
     params: {
       children: 10,
       includeHidden: true,
-      properties: { withName: ["sale"] },
+      properties: { withName: ['sale'] },
     },
-  });
+  })
   ```
 
 ### Patch Changes
@@ -1943,16 +1936,16 @@
     nitro: {
       storage: {
         redis: {
-          driver: "redis",
-          host: "localhost",
+          driver: 'redis',
+          host: 'localhost',
         },
         db: {
-          driver: "fs",
-          base: "./.data/db",
+          driver: 'fs',
+          base: './.data/db',
         },
       },
     },
-  });
+  })
   ```
 
   With the introduction of the new approach for configuring storefront storage mounts, the global and shop-specific `storage` option within the `@scayle/storefront-nuxt` runtime configuration has been deprecated.
@@ -2008,7 +2001,6 @@
 **@scayle/storefront-core v8.23.0**
 
 - Minor
-
   - Deprecated attribute group specific utilities `getFlattenedVariantCrosssellings` and
     `getFlattenedMaterialComposition`.
 
@@ -2025,9 +2017,9 @@
   ```typescript
   const idp = useIDP({
     authUrlParameters: {
-      theme: "dark",
+      theme: 'dark',
     },
-  });
+  })
   ```
 
 ### Patch Changes
@@ -2049,7 +2041,6 @@
 **@scayle/storefront-core v8.21.0**
 
 - Minor
-
   - Expose the following filter types from `storefront-api`:
 
   - `FilterItemWithValues`
@@ -2169,25 +2160,22 @@
       storefront: {
         redirects: {
           enabled: true,
-          strategy: "on-missing",
+          strategy: 'on-missing',
         },
       },
     },
-  });
+  })
   ```
 
   Also, keep in mind that when this option is enabled, the redirect logic will only be executed when the request would otherwise result in a 404. There are three ways in which a 404 can occur.
-
   1. No route found
 
-  If there is no matching route for the request's path, the framework will return a 404 response.
-
-  2. `Response` with 404 status
+  If there is no matching route for the request's path, the framework will return a 404 response. 2. `Response` with 404 status
 
   If the request handler returns a `Response` object with a `status` of 404, a 404 response will be returned to the client.
 
   ```typescript
-  return new Response(null, { status: 404 });
+  return new Response(null, { status: 404 })
   ```
 
   3. Thrown H3Error with 404 status
@@ -2195,8 +2183,8 @@
   If the request handler throws an H3Error with a `statusCode` 404, a 404 response will be returned to the client.
 
   ```typescript
-  import { createError } from "h3";
-  throw createError({ statusCode: 404 });
+  import { createError } from 'h3'
+  throw createError({ statusCode: 404 })
   ```
 
 ### Patch Changes
@@ -2431,7 +2419,6 @@
 - Deprecate `key`, `packages`, `shippingDates`, `isEmpty`, `countWithoutSoldOutItems`, `removeItem`, `contains`, `findItem`, `products`, `generateBasketKey` and `mergeBaskets` from `useBasket`.
 
   Required updates:
-
   - `key`:
 
     ```TypeScript
@@ -2638,28 +2625,28 @@
   **rpc-methods.ts**
 
   ```typescript
-  import type { RpcContext, RpcHandler } from "@scayle/storefront-nuxt";
+  import type { RpcContext, RpcHandler } from '@scayle/storefront-nuxt'
 
   export const foo: RpcHandler<string, number> = function testing(
     param: string,
-    _: RpcContext
+    _: RpcContext,
   ) {
-    return param.length;
-  };
+    return param.length
+  }
   ```
 
   **module.ts**
 
   ```typescript
   function setup() {
-    const resolver = createResolver(import.meta.url);
+    const resolver = createResolver(import.meta.url)
 
-    nuxt.hook("storefront:custom-rpc:extend", (customRpcImports) => {
+    nuxt.hook('storefront:custom-rpc:extend', (customRpcImports) => {
       customRpcImports.push({
-        source: resolver.resolve("./rpc-methods.ts"),
-        names: ["foo"],
-      });
-    });
+        source: resolver.resolve('./rpc-methods.ts'),
+        names: ['foo'],
+      })
+    })
   }
   ```
 
@@ -2870,7 +2857,6 @@
 
   You'll need to migrate your existing storage settings to the new `storefront.storage` format.
   Check the [SCAYLE Resource Center](https://scayle.dev/en/core-documentation/storefront-guide/storefront-application/technical-foundation/storage) for more details.
-
   - _No Longer Supported: Legacy Storage Setup in (`nuxt.config.ts`):_
 
     ```ts
@@ -2881,23 +2867,23 @@
         storefront: {
           // ...
           redis: {
-            host: "localhost",
+            host: 'localhost',
             port: 6379,
-            prefix: "",
-            user: "",
-            password: "",
+            prefix: '',
+            user: '',
+            password: '',
             sslTransit: false,
           },
           // ...
           session: {
             // ...
-            provider: "redis",
+            provider: 'redis',
           },
         },
         // ...
       },
       // ...
-    });
+    })
     ```
 
   - _Current Unified Storage Approach (`nuxt.config.ts`):_
@@ -2911,13 +2897,13 @@
           // ...
           storage: {
             cache: {
-              driver: "redis",
-              host: "localhost",
+              driver: 'redis',
+              host: 'localhost',
               port: 6379,
             },
             session: {
-              driver: "redis",
-              host: "localhost",
+              driver: 'redis',
+              host: 'localhost',
               port: 6379,
             },
             // ...
@@ -2927,11 +2913,10 @@
         // ...
       },
       // ...
-    });
+    })
     ```
 
 - **\[💥 BREAKING\]** The composable `useSearch` has been replaced by `useStorefrontSearch`, consolidating and transitioning to SCAYLE Search v2.
-
   - _Previous Usage of `useSearch`:_
 
     ```ts
@@ -2953,7 +2938,6 @@
     ```
 
 - **\[💥 BREAKING\]** The previous use of the `useFacet` composable for category-related product listings was overly complex and difficult to customize. To simplify things, dedicated composables are being introduced:
-
   - `useProductsByCategory`: Replaces `useFacet` for fetching products within a specific category.
   - `useFilters` or `useProductListFilters`: Provide focused filter management capabilities.
 
@@ -2989,14 +2973,13 @@
 
 - **\[💥 BREAKING\]** We've renamed the `useNavigationTree` composable to `useNavigationTreeById` for better clarity. Its functionality, parameters and return values stay identical.
 - **\[💥 BREAKING\]** The composable `useQueryFilterState` has been superseded by the `useFilter` and `useAppliedFilters` (part of `@scayle/storefront-product-listing`) composables.
-
   - _Previous Usage of `useQueryFilterState`:_
 
     ```ts
     const { activeFilters, applyFilters, resetFilterUrl, productConditions } =
-      useQueryFilterState();
+      useQueryFilterState()
 
-    applyFilters({ brand: 23, sale: true, maxPrice: 100, minPrice: 0 });
+    applyFilters({ brand: 23, sale: true, maxPrice: 100, minPrice: 0 })
     ```
 
   - _Current Usage of `useFilter` and `useAppliedFilters`:_
@@ -3009,70 +2992,68 @@
       resetFilters,
       resetPriceFilter,
       resetFilter,
-    } = useFilter();
+    } = useFilter()
 
-    applyPriceFilter([0, 100]);
-    applyBooleanFilter("sale", true);
-    applyAttributeFilter("brand", 23);
+    applyPriceFilter([0, 100])
+    applyBooleanFilter('sale', true)
+    applyAttributeFilter('brand', 23)
 
-    const route = useRoute();
+    const route = useRoute()
     const {
       appliedFilter,
       appliedFiltersCount,
       appliedAttributeValues,
       appliedBooleanValues,
       areFiltersApplied,
-    } = useAppliedFilters(route);
+    } = useAppliedFilters(route)
     ```
 
 - **\[💥 BREAKING\]** The `getBadgeLabel` helper function has been removed, giving you more control over badge label display.
-
   - **Note:** This change doesn't affect projects using SCAYLE Storefront Boilerplate v1.0 or later.
   - For applications based on older versions or using `getBadgeLabel`, you can refer to the previous implementation below:
 
     ```ts
     const BadgeLabel = {
-      NEW: "new",
-      SOLD_OUT: "sold_out",
-      ONLINE_EXCLUSIVE: "online_exclusive",
-      SUSTAINABLE: "sustainable",
-      PREMIUM: "premium",
-      DEFAULT: "",
-    } as const;
+      NEW: 'new',
+      SOLD_OUT: 'sold_out',
+      ONLINE_EXCLUSIVE: 'online_exclusive',
+      SUSTAINABLE: 'sustainable',
+      PREMIUM: 'premium',
+      DEFAULT: '',
+    } as const
 
     type BadgeLabelParamsKeys =
-      | "isNew"
-      | "isSoldOut"
-      | "isOnlineOnly"
-      | "isSustainable"
-      | "isPremium";
-    type BadgeLabelParams = Partial<Record<BadgeLabelParamsKeys, boolean>>;
+      | 'isNew'
+      | 'isSoldOut'
+      | 'isOnlineOnly'
+      | 'isSustainable'
+      | 'isPremium'
+    type BadgeLabelParams = Partial<Record<BadgeLabelParamsKeys, boolean>>
 
     const getBadgeLabel = (params: BadgeLabelParams = {}): string => {
       if (!params) {
-        return BadgeLabel.DEFAULT;
+        return BadgeLabel.DEFAULT
       }
       const { isNew, isSoldOut, isOnlineOnly, isSustainable, isPremium } =
-        params;
+        params
 
       if (isNew) {
-        return BadgeLabel.NEW;
+        return BadgeLabel.NEW
       } else if (isSoldOut) {
-        return BadgeLabel.SOLD_OUT;
+        return BadgeLabel.SOLD_OUT
       } else if (isOnlineOnly) {
-        return BadgeLabel.ONLINE_EXCLUSIVE;
+        return BadgeLabel.ONLINE_EXCLUSIVE
       } else if (isSustainable) {
-        return BadgeLabel.SUSTAINABLE;
+        return BadgeLabel.SUSTAINABLE
       } else if (isPremium) {
-        return BadgeLabel.PREMIUM;
+        return BadgeLabel.PREMIUM
       } else {
-        return BadgeLabel.DEFAULT;
+        return BadgeLabel.DEFAULT
       }
-    };
+    }
     ```
 
 - **\[💥 BREAKING\]** The `store` option in the module configuration has been removed. `@scayle/storefront-nuxt@7.84.0` introduced the `shops` option as a replacement, but maintained backward compatibility with the `store` option. Going forward, configuring shops must be done using the `shops` keyword.
-
   - For more information, please refer to the [documentation](https://scayle.dev/en/core-documentation/storefront-guide/storefront-application/technical-foundation/configuration#shops).
   - **NOTE:** These changes might impact your environment variables used for deployments. Please check your infrastructure and deployment setup and adapt accordingly!
   - _Previous Store Configuration in `nuxt.config.ts`:_
@@ -3092,7 +3073,7 @@
         // ...
       },
       // ...
-    });
+    })
     ```
 
   - _Previous Environment Variables for Store Configuration:_
@@ -3121,7 +3102,7 @@
         // ...
       },
       // ...
-    });
+    })
     ```
 
   - _Current Environment Variables for Shops Configuration:_
@@ -3135,14 +3116,13 @@
 
 - **\[💥 BREAKING\]** To better align with the current Nuxt 3 architecture make key handling more explicit, we've simplified how you interact with the key parameter in RPC composables from version 8 onwards.
   Instead of placing the key within the composable's options object, you'll now provide it as the second argument when calling the composable.
-
   - _Previous `key` as options parameter:_
 
     ```ts
     useProduct({
       // ...
-      key: "productKey",
-    });
+      key: 'productKey',
+    })
     ```
 
   - _Current `key` as dedicated composables argument:_
@@ -3152,13 +3132,12 @@
       {
         // ...
       },
-      "productKey"
-    );
+      'productKey',
+    )
     ```
 
 - **\[💥 BREAKING\]** Introducing a new feature flag `storefront.legacy.enableSessionMigration` to control the automatic migration of legacy session data, set to `false` by default. Starting with `@scayle/storefront-nuxt@7.68.0` Storefront uses unique session cookie names for each shop, simplifying implementation and enhancing stability.
   Instead of relying on the Path attribute, each shop receives a distinct cookie name. This change is internal and should not require code modifications.
-
   - _Cookie format before `@scayle/storefront-nuxt@7.68.0`:_
     - `Set-Cookie: $session=s:fa3746f9-88c8-4065-a6c9-0c7bee473dd8.pSoaN6Q7iFHHyWKE7s9gQAqdDzGb9fS8a478P7PHLxw; Path=/de`
   - _Cookie format after `@scayle/storefront-nuxt@7.68.0`:_
@@ -3166,61 +3145,57 @@
   - **NOTE:** Upgrading directly to this version from a version prior to `@scayle/storefront-nuxt@7.68.0` without enabling the `storefront.legacy.enableSessionMigration` feature flag will lead to loss of user sessions. Ensure version `@scayle/storefront-nuxt@7.68.0` or higher has been deployed in production for a period exceeding the configured session TTL before upgrading to this version. This ensures all legacy sessions have been migrated. Consult the updated documentation for details on the cookie format changes and migration procedures.
 
 - **\[💥 BREAKING\]** We've optimized the way Identity Provider (IDP) logins are handled. Instead of using the `handleIDPLoginCallback` RPC method, which has been removed, from the `useIDP` composable, you'll now use the `loginIDP` function, which has been moved to the `useAuthentication` composable. This change consolidates IDP login functionality within `useAuthentication` for a more unified approach.
-
   - _Previous Usage of `handleIDPLoginCallback`:_
 
     ```ts
-    const { handleIDPLoginCallback } = await useIDP();
+    const { handleIDPLoginCallback } = await useIDP()
 
     watch(
       () => route.query,
       async (query) => {
         if (query.code && isString(query.code)) {
-          await handleIDPLoginCallback(query.code);
+          await handleIDPLoginCallback(query.code)
         }
       },
-      { immediate: true }
-    );
+      { immediate: true },
+    )
     ```
 
   - _Current Usage of `loginIDP`:_
 
     ```ts
-    const { loginIDP } = useAuthentication("login");
+    const { loginIDP } = useAuthentication('login')
 
     onMounted(async () => {
-      await loginIDP(props.code);
-    });
+      await loginIDP(props.code)
+    })
     ```
 
 - **\[🧹 NON-BREAKING\]** Addressed various type resolution errors that were present when using the `@scayle/storefront-nuxt` package with different Node.js versions and module systems. These errors manifested as internal resolution errors or ESM dynamic import only warnings. With this fix, the package now more consistently resolves types correctly across Node.js 16 (CJS and ESM), and bundlers, ensuring a smoother developer experience.
 - **\[💥 BREAKING\]** The `useBasket` composable now gracefully handles cases where adding items to the basket results in a smaller quantity being added than originally requested by checking against `AddToBasketFailureKind`.
 - **\[💥 BREAKING\]** The deprecated `autoFetch` option of `useRpc` has been removed in favor of the `immediate` option. This also applies to all data fetching composables provided by `@scayle/storefront-nuxt`.
-
   - _Previous `useRpc` with `autoFetch`:_
 
     ```ts
-    useRpc("rpcMethod", key, params, { autoFetch: true });
+    useRpc('rpcMethod', key, params, { autoFetch: true })
 
-    useUser({ autoFetch: true });
+    useUser({ autoFetch: true })
     ```
 
   - _Current `useRpc` with `immediate`:_
 
     ```ts
-    useRpc("rpcMethod", key, params, { immediate: true });
+    useRpc('rpcMethod', key, params, { immediate: true })
 
-    useUser({ immediate: true });
+    useUser({ immediate: true })
     ```
 
 - **\[💥 BREAKING\]** The attribute `isCmsPreview` has been removed from `RpcContext`.
 - **\[💥 BREAKING\]** The attribute `storeCampaignKeyword` has been removed from `RpcContext`.
-
   - The `campaignKey` is now automatically determined by fetching campaign data through the Storefront API client by retrieving a list of all campaigns from the API. It then narrows down the list by filtering for campaigns that are still active, ensuring any returned campaign is currently running. These active campaigns are then sorted by their start date, ensuring chronological order. Finally, it iterates through the sorted campaigns to find the first one that is currently active, returning its key as an identifier. If no active campaign is found or an error occurs, it returns nothing.
   - The `storeCampaignKeyword` is also no longer used to determine the active campaign key. The functionality to run only certain campaigns for specific countries is now supported through the SCAYLE Panel out of the box.
 
 - **\[💥 BREAKING\]** The composable `useStorefrontSearch` is now consistent with `useRpc` return values. The `fetching` boolean is replaced by `status` with states `idle`, `pending`, `error` or `success`.
-
   - _Previous `useStorefrontSearch` returning `fetching`:_
 
     ```ts
@@ -3230,24 +3205,23 @@
       getSearchSuggestions,
       fetching,
       ...searchData
-    } = useStorefrontSearch(searchQuery, { key });
+    } = useStorefrontSearch(searchQuery, { key })
 
-    fetching.value; // true or false
+    fetching.value // true or false
     ```
 
   - _Current `useStorefrontSearch` returning `status`:_
 
     ```ts
     const { data, resolveSearch, getSearchSuggestions, status, ...searchData } =
-      useStorefrontSearch(searchQuery, {}, key);
+      useStorefrontSearch(searchQuery, {}, key)
 
-    status.value; // 'idle', 'pending', 'error' or 'success'
+    status.value // 'idle', 'pending', 'error' or 'success'
     ```
 
 - **\[💥 BREAKING\]** We've simplified composable caching and clarified the control you have over shared state behavior. The configuration option `disableDefaultGetCachedDataOverride` has been replaced with `legacy.enableDefaultGetCachedDataOverride`, and its logic has been reversed. Now, when `legacy.enableDefaultGetCachedDataOverride` is not set or set to `false`, the default behavior maintains the shared state functionality of `useRpc`, where multiple calls with the same key use the same cached data. Setting the option to `true` bypasses this shared caching, providing data isolation between calls. To maintain your existing caching behavior, simply change the value of `disableDefaultGetCachedDataOverride` to its opposite in your `nuxt.config.ts` file.
 
   Old config
-
   - _Previous `disableDefaultGetCachedDataOverride` in `nuxt.config.ts`:_
 
     ```ts
@@ -3266,7 +3240,7 @@
         // ...
       },
       // ...
-    });
+    })
     ```
 
   - _Current `enableDefaultGetCachedDataOverride`in `nuxt.config.ts`:_
@@ -3291,14 +3265,13 @@
         // ...
       },
       // ...
-    });
+    })
     ```
 
 - **\[💥 BREAKING\]** The `useRpc` composable has been updated to provide a more modern and robust data fetching experience, aligning its interface with the current and underlying [Nuxt 3 `useAsyncData`.](https://nuxt.com/docs/api/composables/use-async-data#return-values).
   The separate `fetch` function has been replaced with a single, intuitive `refresh` function that can be used to refresh the data returned by the `handler` function.
   Additionally, the boolean `pending` flag has been superseded by a more informative `status` return value, offering greater insight into the fetching lifecycle with possible states: `idle`, `pending`, `success`, and `error`.
   These changes enhance the developer experience and provide greater clarity and control over data fetching operations within components.
-
   - **NOTE:** This update not only impacts the `useRpc` composable directly, but also extends to other RPC composables relying on it, such as `useProducts` and `useCategories`!
 
 - **\[💥 BREAKING\]** Removed special handling for `BAPIError` and `BaseError` thrown in RPC methods. These custom `Error` classes were previously used in RPC methods to allow customizing the status code and message of errors.
@@ -3306,14 +3279,13 @@
   In this release, the legacy special handling for `BAPIError` and `BaseError` has been removed. Now they will be treated like any other `Error`. If they are thrown uncaught during the execution of an RPC method, a 500 status code will be used in the response. They have also been removed from `@scayle/storefront-nuxt`.
   For most users, this change will have no impact as the core RPC methods have been updated for some time. However, if you have custom RPC methods you should review their implementation.
   In order to have an RPC method use a specific status code, it should return a `Response` object.
-
   - _Previous Usage with `BaseError`:_
 
     ```ts
     function myCustomRpc() {
       // ...
 
-      throw new BaseError(404);
+      throw new BaseError(404)
     }
     ```
 
@@ -3323,7 +3295,7 @@
     function myCustomRpc() {
       // ...
 
-      return new Response(null, { status: 404 });
+      return new Response(null, { status: 404 })
     }
     ```