Skip to main content
Version: 3.x

3.5 -> 3.6

This page lists the highlights for upgrading a project from Front-Commerce 3.5 to 3.6

Use the latest pnpm version

We now support pnpm version 9 and above. In the past, we may have recommended to stick to pnpm version 8. This is no longer the case.

Please make sure to update your pnpm version to the latest one.

$ pnpm add -g pnpm
$ pnpm -v
9.7.0 # or higher

Update dependencies

Update all your @front-commerce/* dependencies to this version:

pnpm update "@front-commerce/*@3.6.0"
REACT 18 CANARY

We have pinned the react and react-dom version to 18.3.0-canary, this resolves an issue with hydration during HMR changes. See issue for more details.

To update your project, you can do the following:

pnpm update react@18.3.0-canary-c3048aab4-20240326 react-dom@18.3.0-canary-c3048aab4-20240326

We also suggest adding resolutions to your package.json to ensure the same version of React is used in your project:

package.json
{
"resolutions": {
"react": "18.3.0-canary-c3048aab4-20240326",
"react-dom": "18.3.0-canary-c3048aab4-20240326"
}
}

We suspect that this fix will only be released in React 19.

Automated Migration

We provide a codemod to automatically update your codebase to the latest version of Front-Commerce. This tool will update your code when possible and flag the places where you need to manually update your code (with // TODO Codemod comments).

pnpm run front-commerce migrate --transform 3.6.0

Changes introduced with this automated migration script:

  • Adds pazyen flavor to extension options (example)
  • Replace usage of limitRateByClientIp with limitRateByGraphQLResolver (example)
  • Rename mutation types with new conventions (example, ADR)

Custom Scalar support in GraphQL schema

In this release, we've introduced a new way to define custom scalars in your GraphQL schema.

To learn more please refer to the Custom Scalars guide.

note

If you have patched to core to allow for custom scalars, you can now safely remove the patch.

Cache-Control headers

In this version, we introduced a way to add Cache-Control headers to responses using a new CacheControl service available through FrontCommerceApp.

With this new feature, we also added its usage to a few existing routes:

  • _main._index.ts
  • _main.category.$id.tsx
  • _main.product.$id.tsx
  • robots[.txt].ts
  • sitemap[.xml].ts

To enable Cache-Control headers on those routes (if you already overrode them), you will need to add the usage of this new service in these routes' loaders like so:

_main._index.tsx
export const loader: LoaderFunction = ({ context }) => {
const app = new FrontCommerceApp(context.frontCommerce);
app.services.CacheControl.setCacheable({
sMaxAge: 60,
staleWhileRevalidate: 21600,
});

return {};
};
info

For more information about this change, see the related commit.

Server timings

In this version we introduced a new ServerTimings service that is used to generate and append Server-Timing headers to reponses.

This contains a change to app/entry.server.tsx, which you will have to update to properly benefit from this new feature:

app/entry.server.tsx
diff --git a/app/entry.server.tsx b/app/entry.server.tsx
index 7783303fd..a8f621d20 100644
--- a/app/entry.server.tsx
+++ b/app/entry.server.tsx
@@ -99,6 +99,7 @@ function handleBrowserRequest(
remixContext: EntryContext,
loadContext: AppLoadContext
) {
+ loadContext.frontCommerce.services.ServerTimings.start("SSR");
return new Promise(async (resolve, reject) => {
const { pipe, abort } = renderToPipeableStream(
await prepareV2ServerRenderedApp(
@@ -121,6 +122,7 @@ function handleBrowserRequest(

responseHeaders.set("Content-Type", "text/html");

+ loadContext.frontCommerce.services.ServerTimings.end("SSR");
resolve(
new Response(body, {
headers: responseHeaders,
@@ -131,6 +133,7 @@ function handleBrowserRequest(
pipe(body);
},
onShellError(error: unknown) {
+ loadContext.frontCommerce.services.ServerTimings.end("SSR");
reject(error);
},
onError(error: unknown) {

Learn how to use this new feature for your own code in the Add your own server timings guide.

Payzen Module

In this version, we introduced Payzen compatibility for Magento 2.

info

If a flavor has not yet been added, then this will default to front-commerce-magento1 after running the automated migration

.front-commerce.config.ts
// ...
import payzen from "@front-commerce/payzen";

export default defineConfig({
// ...
extensions: [
// ...
// For Magento 1 usage
payzen("front-commerce-magento1")
// For Magento 2 usage
payzen("front-commerce-magento2")
// ...
]
// ...
});

Flash messages

We have implemented a new flash message system that allows you to display messages after certain actions.

The legacy system have been replaced, and some tweaks may be needed to existing code.

Please refer to this commit for more details.