# Changes description and Migrate version 0.8.x to 0.9.x
POTENTIAL DEPENDENCY PROBLEMS
In case of problems with dependencies (mismatch, not installed, etc...) that may appear, we encourage you to follow those steps:
- update the version in package.json (
@shopware-pwa/nuxt-module
) yarn upgrade
yarn shopware-pwa init
(ornpx @shopware-pwa/cli@canary init
)yarn dev
(do not use npx for anything else than init)
what else could help if not this:
- remove
node_modules
directory andyarn.lock
file - (DO BACKUP BEFORE) remove
nuxt.config.js
and invokenpx @shopware-pwa/cli init
# Nuxt config changes BREAKING CHANGE
In order to provide better experience we want to keep your nuxt.config.js
file as clean as possible.
You can now safely remove all things you didn't put there by yourself. Newly generated nuxt.config.js
file can look like this
import extendNuxtConfig from "@shopware-pwa/nuxt-module/config";
export default extendNuxtConfig({
head: {
title: "Your Shop Name",
meta: [{ hid: "description", name: "description", content: "" }],
},
});
TIP
It will not break your current project, but not using extendNuxtConfig
method can cause troubles in the future. That's why this is marked as a breaking change
WARNING
If there is any problem with extending the config and you already has been using the customized one, please copy the content of an object from this file (opens new window) and put it in the nuxt.config.js
(merge both configs if it's needed).
But keep in mind that you will loose the compatibility with the config shipped in the core. It's always better to report an issue (opens new window) in case of extending functionality does not work well.
# CMS for Product Detail Pages
With Shopware 6.4 and Shopware PWA 0.9 you can now use CMS inside Product Detail Pages. It works the same way as other CMS pages, we added few new Blocks and Elements. You can read about the whole concept here
# Native TypeScript support
You can use TypeScript natively across the project, plugins, theme and logic.
Just add <script lang="ts">
in your components to start using it there. All your files can be written in .ts
files.
# Breaking changes within packages BREAKING CHANGE
# @shopware-pwa/shopware-6-client
SearchResult interface has been replaced with EntityResult<ENTITY, ENTITY_TYPE> interface as a response in listed methods:
createGuestOrder
getAvailableCountries
getAvailableCurrencies
getAvailableLanguages
getAvailablePaymentMethods
getAvailableShippingMethods
getAvailableSalutations
Removed methods (not supported in v6.4.x):
addCartItemQuantity
createGuestOrder
getCheckoutGuestOrderDetailsEndpoint
getCheckoutGuestOrderEndpoint
getContextCountryItemEndpoint
getContextPaymentMethodDetailsEndpoint
getContextSalutationItemEndpoint
getContextShippingMethodDetailsEndpoint
getOrderPaymentUrl
(handlePayment
method is a replacement)
# @shopware-pwa/composables
- Changed behavior
- Guest customer's data is not kept in shared state within
createCheckoutStep
anymore.
- Guest customer's data is not kept in shared state within
- Removed (not supported in v6.4.x):
createGuestOrder
,isGuestOrder
,updateGuestOrderParams
fromuseCheckout
.useProductListing
composableuseProductSearch
composable
# [default-theme] Upgrading to Vuelidate v2 (potential Breaking Change)
We upgraded validation library to fully use possibilities of Composition API. If you encounter some problems with validation please follow Vuelidate's migration guide: https://vuelidate-next.netlify.app/migration_guide.html
Basic migration has 3 steps:
- changing imports
- removing mixin from component
- adding
$v: useVuelidate(),
in setup'sreturn
# [default-theme] Upgrading to Storefront-ui v0.10 (potential Breaking Change)
With this release, we upgraded storefront-ui to the newest version. This required style improvements and changes in multiple components. Potentially it may break some styling in your overwritten components, shouldn't be anything too hard to fix though.
# [default-theme] Extended checkout's payment flow
Following flow from https://github.com/vuestorefront/shopware-pwa/issues/1419 the payment flow has changed in terms of how the customer is being redirected. When the selected payment method implements async payment - once the order is placed the customer is being redirected immediately to the external payment gateway. Depending on a result of the payment the customer is redirected back in both scenarios: failure and success to the corresponding routes:
- /order-success - when the payment was done without any problems, or the payment does not require additional redirections to the external providers.
- /payment-failure - when the payment gateway tells the API the payment isn't finished properly.
In case of problems during placing an order itself - no redirection is made, just appriopriate notifications are shown on the review step.