Release: 3.4 & 2.29
Vite, Vite, Vite!β
We are thrilled to announce that Front-Commerce has migrated to Vite! π
Vite is a tool that helps web developers build websites and web applications
faster.
Front-Commerce 3.4 takes the development experience to a whole new level. We have migrated the frontend tooling of Front-Commerce projects from the Classic Remix Compiler to Vite. In an AI-assisted development environment, having fast feedback is key to productivity. That's why bringing faster development feedback was important to us. It also means that Front-Commerce now benefits from the latest features and improvements of the Vite ecosystem.
In addition to these technical changes under the hood, we have also introduced new features and improvements to the core of Front-Commerce. We have stabilized new public core APIs for developers, added new payment modules, and enhanced the testing experience for instant feedback π
This release is very dense as it spans two usual release periods. Due to the technical challenges of migrating to Vite, we needed more time to ensure a smooth transition and a great developer experience. We hope this extended delay will be worth it for you.
π We would like to thank our partners Adexos, PH2M, and Webqam for their valuable feedback during the beta testing phase of this Vite version. Their input has been crucial in ensuring the quality of this release.
π€ If you haven't tried Front-Commerce 3.x yet, now is the perfect time to do so. Let's dive into the details of Front-Commerce 3.4!
From the Classic Remix Compiler to Viteβ
Front-Commerce follows the path of Remix and migrates to Vite. We've been waiting for this moment for a long time, and since Remix announced its stable Vite support at the end of february, we've been working hard to make this migration possible.
A Front-Commerce project is now a Vite project with the
Remix Vite plugin,
enhanced by the Front-Commerce Vite Plugin (from @front-commerce/remix
) π€―
Every feature brought by Front-Commerce has been reinvented in a Vite-compatible way. This includes Extensions, PWA generation, GraphQL code generation, theme overrides, unified configuration and more.
As a result, the development experience is unified, more memory efficient and faster than ever. All of this thanks to Vite's blazing fast development server, HMR and build times.
The migration to Vite allowed us to simplify many things, and fix a few annoying flaws. Here are some highlights:
- in development, you can now benefit from instant reloads when you update your theme but also when you update an environment variable or a GraphQL module
- you can now directly import your SCSS file in components (instead of a generated CSS)
- you can now override a component SCSS file in your project without having to
create a sibling
tsx
file reexporting the original component - routes don't require a parent layout if it exists in a parent theme, and you
don't need an empty
root.tsx
in yourroutes
directory anymore - we're now enforcing the use of ESM modules everywhere: no more CommonJS modules in a Front-Commerce project codebase!
- we replaced several dependencies with ESM alternatives, and patched imports for the ones that were not (yet!) ESM-compatible
It also opens up new possibilities for your project. You can now leverage tools from the Vite ecosystem directly in your project. We have already updated the skeleton to use Storybook 8 (Vite compatible) and added some example stories to help you get started. Similarly, we have updated the skeleton to use Vitest for testing and included some sample tests to assist you.
We have also provided documentation for a working example extension that demonstrates how to use Tailwind within a Front-Commerce project. Additionally, we are working on more examples (such as MDX) to help you effectively utilize the Vite ecosystem.
From Jest to Vitestβ
We took this opportunity to migrate our entire test suite from Jest to Vitest. This change brings more consistency between the application and tests, simplifies the codebase, and improves overall test performance.
Please, read the Your first test
guide to learn more about how to use it to improve the quality of your project.
We started to expose some useful testing utilities in our packages, such as the
FrontCommerceProviderStub
to help you test your components in isolation. Let
us know if you need more utilities to test your project!
π One of the first things our support team does when receiving a bug report is to find a way to reproduce the issue. A test case is the best way to ensure that the bug is fixed and that it doesn't come back in the future.
π₯° If you can provide a test case, it will help us to understand the issue and fix it fasterβ¦ π
Speaking of tests, we also updated the version of the Pact library (used for testing interactions with remote services) to the latest one. This involved a huge effort from the team, but that's for the best! Since Pact 10, the Ruby implementation has been replaced by a Rust one, which is much faster.
Our test suite now runs twice as fast as before! π
This speed
improvement will allow us to iterate faster and with more confidence.
New stable APIs in the coreβ
Public APIs play a crucial role in the experience of a software product like Front-Commerce. They provide a standardized and documented interface for developers to interact with the product's functionality. At Front-Commerce, we aim to provide a stable and reliable API for our customers so that they could upgrade to new versions without breaking their existing codebase.
These APIs also ensure that people can contribute to the product's growth by developing plugins, extensions, and integrations.
We wanted to wait for the Vite migration to stabilize as it impacted many parts of our codebase. Now that it's done, we are happy to introduce new stable APIs in the core of Front-Commerce.
GraphQL Module stable APIβ
We reworked how GraphQL modules are registered to introduce a clearer and more
declarative graphql.modules
registration API for extensions and app authors.
While conceptually similar to the way a GraphQL module was registered in 2.x, the new API more clearly separates the concerns of a GraphQL module:
- the module definition (using
createGraphQLModule
) is loaded with yourfront-commerce.config.ts
configuration declaration. It is a plain Javacript object that declares the responsibilities of the module and its role in the application. It is where you'll define the schema, name, and dependencies of the module. - the module runtime (using
createGraphQLRuntime
) is a lazy-loaded module that is only loaded when the application starts. It is where you'll define theresolvers
andcontextEnhancer
of your module, that is, the code that will be executed when a GraphQL query is made.
We hope this new API will make it easier for you to understand and maintain your
GraphQL modules. We implemented several transformers in the
@front-commerce/codemod
3.4 migration, to help you migrate your codebase to
this new API.
Read the migration guide for more information about these changes.
Sitemap APIβ
Front-Commerce 3.4 introduces a revamped way to generate sitemaps. The new API is more flexible and is based on Remix routes instead of CRON jobs.
Here are some highlights of the new API:
- Front-Commerce will automatically include static routes in the generated sitemap
- You can customize the content of the sitemap at route level using your route
handle
export - We provide a
createSeoHandle()
helper to achieve the most common use cases with a few lines of code - Dynamic routes can leverage Sitemap fetchers from registered extensions
(through the
SitemapService
) to generate URLs based on data from remote systems (like Magento or Contentful)
Here is a high-level overview of the SitemapService
design:
Read the Customize the sitemap guide for a more technical overview of this new API.
Our core modules @front-commerce/theme-chocolatine
, @front-commerce/magento1
and @front-commerce/magento2
has been updated to use this new API.
This API was inspired by the work of @balavishnuvj/remix-seo and the NASA GCN fork. Thanks to them for their contributions!
External Loginβ
This release introduces the ability for customers to login and register with
external providers thanks to the new @front-commerce/external-login-providers
package.
We revamped how this feature was implemented under the hood and crafted public APIs that we hope are simple to use and extend than their 2.x counterparts:
- Providers: Providers are responsible for handling authenticating the user with the external systems. We support Google and Facebook out of the box, and you can add or contribute your own providers.
- Adapters: Adapters allow you to link external services users to your e-commerce customer account. We support Magento2 out of the box, and Magento1 support will come soon.
Read the External Login Providers documentation to learn more about this feature.
Rate Limitingβ
We implemented a RateLimiter
core service to limit calls on pages. This
feature is useful to prevent abuse of your website:
- Rate limiting follows the best practices and HTTP standards
- You can use the
RateLimiter
service in your GraphQL resolvers or in your Remix loaders/actions to limit the number of requests a user can make in a given time frame. - The
RateLimiter
service uses Redis to store the rate limits in a scalable way. - You can configure the rate limits per namespace, allowing you to have different rate limits for different parts of your application.
Read the Prevent excessive usage with rate limits guide to learn more about this feature.
Simplified some entrypoints for standard use casesβ
When we introduced Front-Commerce Remixed, our goal was to seamlessly integrate it into a standard Remix project. This meant that projects would have complete ownership of the Remix entrypoints, including the server module and server/client entry.
However, this approach had some drawbacks. It made updates more tedious for projects that only used the default configuration, as they had to manually apply changes to their entrypoints in order to benefit from the low-level improvements brought by Front-Commerce.
In Front-Commerce 3.4, we introduce a simpler API for some of them. We have
extracted our default logic for the express server and the service worker into
the @front-commerce/remix
package, allowing projects to use the default
configuration with just one line of code.
This eliminates the need for
manual entrypoint modifications and simplifies the update process.
Of course, projects still have the flexibility to "eject" from the default configuration for more advanced use cases.
New payment modules supported in 3.xβ
We are keeping the pace of migrating modules from 2.x to 3.x. This release introduces the following payment modules:
@front-commerce/paypal
now support Paypal for Magento1 and Magento2.@front-commerce/payzen
has implemented the Payzen Payment method for Magento1.@front-commerce/stripe
has implemented the Stripe Payment method for Magento1 and Magento2.
You'll find the full list of supported services in the "Extensions" section of our documentation's sidebar. We've alphabetically sorted them to make it easier to find the one you're looking for.
Backed by codemods!β
As you noticed, this release is packed with changes. It was a huge effort on our side and led to changes in several parts of code you own.
We have invested a lot of time in creating a set of codemods to deal with the tedious and bug-prone task of code updates. It should help you migrate seamlessly to Front-Commerce 3.4.
We hope this will make your migration process as straightforward as possible but invite you to rigorously follow the instructions in the migration guide to prevent issues.
π As always, we are here to help you with the migration process. If you encounter any issues, please don't hesitate to reach out to our support team.
Other changesβ
Features
- 2.x only: we added support for rolling sessions, to renew the session duration for recurring users.
- Maintenance Mode: we added a maintenance mode feature to the
@front-commerce/remix
package, to temporarily disable your shop for maintenance. - User: we introduced the
UserJourney
class and exposed it asuser.journey
to track events and actions taken by users, and ensure they are only tracked once. - DX: we now allow to customize success / failure HTTP codes for healthcheck
using
successHTTPCode
andfailureHTTPCode
search params, to better test your healthcheck in your CI/CD pipeline or cloud environment. - DX: we now prevent the application to start if no
FRONT_COMMERCE_COOKIE_PASS
environment variable is defined. - DX: we implemented a custom
axios-debug-log
instance to help you debug your external API calls. - DX: we removed the Magento2 configuration from the default
front-commerce.config.ts
so that it's unopinionated and allows to start a project or reproduction from a simpler setup.
Bug Fixes
We fixed several bugs in this release, based on the feedback we received from our customers and partners and from our internal testing sessions.
These bug fixes were also backported to 2.x
when relevant.
-
Impersonation: we fixed an issue where the impersonation redirection URL was not using the current domain.
-
Service Worker: we prevented blocking deferred response streaming in the service worker.
-
Front-Commerce Postinstall: we improved the
front-commerce-postinstall
script for more reliable updates. -
Core: Fixed import location of RestPagesWalker from core.
-
Magento:
- we fixed an issue with the
makeAxiosInstance
function being passed the wrongauthToken
parameter in the case of anAdminInstance
. - Fixed import location for USER_CACHE_ROOT in
perMagentoCustomerGroup
. - Fixed an issue where the magento checkout graphql module is overridden by the front-commerce checkout module.
- Magento1: we fixed an issue where the token invalidation was not detected correctly.
- Magento1: Fixed an issue with Magento1 module address formatting method not passing the right property for addresses' ids.
- Magento2: Fixed an issue with categories ID being in base64 in Magento2 >2.4.6.
- Magento2: Prevent a race condition for guest carts just placed: inactive carts are now considered as a 404.
- we fixed an issue with the
-
Analytics:
- we fixed an issue where the
OrderPlaced
event was tracked multiple times upon page refresh. - we fixed an issue with the
Product searched
event payload in e-commerce analytics plugin. - we fixed an issue with the properties usage in the Google Analytics e-commerce plugin.
- we fixed an issue where the
-
UI:
- we fixed an issue where the customer id was not tracked when the user was logged in for checkout success.
- we fixed an issue where the quantity selector was not properly initialized.
- we fixed an issue where switches were not updated properly in the Editorial toolbox
- Fixed an issue where
/orders/:id
resolves to/orders
route, due to it not being marked as an index route. - Fixed an issue where
/requisition-lists/:id
resolves to/requisition-lists
route, due to it not being marked as an index route. - Fix an issue where defaultQuantity wasn't set when an optional product switch from none to a product.
- Fixed a regression in the
PaymentForm
state management which did not allow state resetting or disabled button click event handler. - Fix an issue where
NumberInput
input component won't be updated if the value is 0. - Fixed an issue when trying to navigate via the
LinkListSelector
due to non-existingprops.history.push
usage resulting in a page error. - Fixed the functional
className
forRouteLink
to correctly use the isActive prop from@remix-run/react
NavLink
component. - Fix an issue for bundle products where default quantity was set even if the product wasn't required.
-
Requisition List: we fixed several edge cases after thorough testing sessions of this feature:
- Fixed an issue causing a crash when trying to add products to a requisition list from PLPs and cart pages. This was due to missing data passed to the component, and to the mutation parameter being incorrect in some cases.
- Fixed an issue with requisition list configuration modal that would not register option selections for configurable products.
- Fix an issue where Page title wasn't updated properly on requisition lists listing.
- Fixed an issue causing the app to crash when selecting an option in the product configuration modal when another select option did not have a value.
- Fix an issue where when adding a product to a requisition list from the cart it adds the SKU of the already configured product instead of the main product with configurables.
- Fixed an issue causing the requisition lists modal to "catch" click event from the configuration modal when trying to add a configurable product to a requisition list.
- Fixed an issue causing the "requisition list" list not to be refreshed when trying to add a product to a requisition list.
- Fixed an issue occurring when trying to add a bundle product to a requisition list from a PLP page. This was due to the fact configuration modal wasn't implemented at all for bundle products. Clicking on "Add to requisition list" from the PLP on a bundle product now redirects to the product's page.
- Fixed a frontend issue preventing a bundle product from being added to a requisition list from a PDP.
- Added missing bundle options when adding bundle products to requisition lists.
- Fixed an issue with RequisitionList loaders not updating cart cache when modifying the cart.
Fixes from 3.4
have also been backported into previous minor versions. The following patch versions were released: 3.3.3
, 3.2.7
, 3.1.5
, 3.0.5
, 2.29.0
, 2.28.2
, 2.27.4
, 2.26.8
, 2.25.11
, and 2.24.12
.