Release Notes

Custom Applications now let you generate deployment previews, where you can test new features without affecting the production version of your application.

If you're using the legacy workaround of creating multiple Custom Applications with different entry points, we recommend migrating to deployment previews. They provide a better developer experience with less maintenance since you only need to configure one Custom Application.

As always, if you have questions or feedback, you can open a GitHub Discussion or a GitHub Issue.

When developing a Custom Application locally, you are prompted to authorize your user via the login form. From now on, it is possible to log into the Merchant Center using Single Sign-On for local development as well.

As always, if you have questions or feedback, you can open a support ticket.

The Application Kit packages have been released with a minor version v21.21.0.

Custom Applications now allow defining more granular OAuth Scopes and user permissions to cover more specific business requirements. You can create multiple permission groups and assign different OAuth Scopes to them. These permission groups can then be assigned to teams in a more granular way.

As always, if you have questions or feedback, you can open a GitHub Discussion or a GitHub Issue.

Custom Applications now use a more readable, customizable document title by default. You can read more about this feature in the Human-readable page title documentation.

As always, if you have questions or feedback, you can open a GitHub Discussion or a GitHub Issue.

By default Custom Applications provide pre-configured HTTP clients for GraphQL and REST API requests.

However, you could use any other HTTP client of your choice, for example Fetch, Axios, Stale-While-Revalidate (SWR), etc.

The main problem with that is the fact that you need to configure these clients on your own, in particular regarding the HTTP headers that should be sent with every request.

To make it easier to configure your HTTP client with the necessary HTTP headers, we provide some dedicated utility functions, in particular the executeHttpClientRequest.

As always, if you have questions or feedback you can open a GitHub Discussion or a GitHub Issue.

With the release of Org-level Custom Applications, one of the long-term goals for this feature was to enable Custom Applications to be configured only once and installed everywhere needed.

Up until now, this functionality was limited to installing a Custom Application in the same Organization where it was configured. This limitation was mainly posed to reduce the scope of the initial release.

As of today, we are happy to announce that Custom Applications can be installed in other Organizations where the user has administration rights.

If you are managing multiple Organizations, you can configure a Custom Application in one of them and install it across the different Organizations where you are a member of the Administrators Team. For more information check out the revised documentation for Configuring and Managing Custom Applications.

As always, if you have questions or feedback you can open a GitHub Discussion or a GitHub Issue.

The migration deadline previously set to the end of July 2022 has been postponed to Friday, 16 September 2022.

This gives users a bit more time to finish the migration from Project-level Custom Applications.

As always, if you have questions or feedback you can open a GitHub Discussion or a GitHub Issue.

The Application Kit packages have been released with a minor version v21.8.

This release includes several new features that we would like to present:

• Official support for developing Custom Applications in TypeScript, including a new starter template. Read more about TypeScript in the Adding TypeScript page.
• New policy option for configuring the audience field when integrating your Custom Application with an external API.
• Improved accessibility of different elements using ARIA attributes.
• Simpler and more readable list of time zone data, available from the @commercetools-frontend/l10n package.
• New React hook useProjectExtensionImageRegex for accessing the project images configuration, available from the @commercetools-frontend/application-shell-connectors package.

As always, if you have questions or feedback you can open a GitHub Discussion or a GitHub Issue.

We are happy to announce that Custom Applications is now generally available.

After collecting feedback during the beta phase, and with the recent milestone of migrating Custom Applications to Org-level, we now have a solid foundation on the functionalities and developer tooling for Custom Applications.

The Application Kit packages have been released with a minor version v21.6.

This release includes several new features that we would like to present:

• A new built-in Stacking Layer System to automatically and consistently calculate z-index values of stacked modal containers.
• New layout UI components <InfoDetailPage>, <FormDetailPage> and <CustomFormDetailPage>.
• The CLI commands config:sync now lists changes when updating an existing Custom Application configuration.
• The Jest preset @commercetools-backend/jest-preset-mc-app contains more Intl polyfills.

As always, if you have questions or feedback you can open a GitHub Discussion or a GitHub Issue.

The Application Kit packages have been released with a minor version v21.3.

This release includes several new features that we would like to present:

• New CLI commands login and config:sync to help maintaining Custom Applications.
• New layout UI components <TabularMainPage> and <TabularDetailPage>. In addition to that, a new <TabHeader> component is exported from the @commercetools-frontend/application-components package to be used in the tabular UI components <TabularModalPage>, <TabularMainPage> and <TabularDetailPage>.
• New ESLint config @commercetools-backend/eslint-config-node for Node.js projects with built-in TypeScript support.
• The notification components now support the aria role alertdialog and the aria-describedby attributes. This helps in particular to write more specific and relevant selector in tests.

As always, if you have questions or feedback you can open a GitHub Discussion or a GitHub Issue.

The Application Kit packages have been released with a new major version v21.

This version marks the release of new Custom Application features. See Migrating from Project-level Custom Applications for more information.

Furthermore, the Custom Application documentation has been restructured and updated to match the new status quo of Custom Applications. The Project-level legacy documentation remains available during the migration period in a separate location.

Follow the steps below to migrate your Application Kit packages to the new version.

The Custom Application Starter template has been rewritten from scratch, to provide a better experience to new developers working on Custom Applications.

Below an overview of the most important changes:

The Application Kit packages have been released with a new major version v19.

This version does not contain explicit changes in our packages but mainly updates to major versions of some of the depended upon libraries. For instance:

• @commercetools-frontend/ui-kit and all @commercetools-uikit/* packages have been updated to v12.
• react and react-dom have been updated to v17.
• graphql has been updated to v15.
• webpack has been updated to v5

Furthermore, some peer dependencies have been updated to only require more recent versions. Please refer to each specific package's CHANGELOG.md.

The Application Kit packages have been released as a new major version v18.

The changes relate to @commercetools-frontend/eslint-config-mc-app package, where eslint is now the only required peer dependency. Additionally, the ESLint config uses the ESLint React App config as a base instead of Airbnb.

Most of the rules have stayed the same, however you may need to adjust or fix some depending on your usage.

In this release we also removed the long deprecated hostnames mc.commercetools.com and mc.commercetools.co from the default Content Security Policy configuration. This is aligned with the long-running effort of moving the Merchant Center to use the new URLs.

If you still want to support your Custom Application to run on the legacy hostname for the remaining time being, you would need to explicitly add the legacy hostname(s) in the connect-src config of the custom-application-config.json.

Follow the steps below to migrate your ESLint config to the new version.

GitHub Discussions is finally generally available! 🎉

We have enabled it in a few selected open source repositories application-kit and ui-kit.

We strongly encourage and recommend to use that as a way of communicating with us (commercetools) and with the community. You can ask questions, share ideas, showcase your work, etc.

You can still use GitHub Issues in case you have to fill an bug report.

We are really excited about it and we hope you find it useful too.

The Application Kit packages have been released as a new major version v17. One of the most important changes in this release is about migrating to the new Apollo Client v3.

Follow the steps below to migrate your Custom Application to the new versions.

This release introduces the usage of a new configuration file format and marks the deprecation of the env.json and headers.json files.

The env.json and headers.json files will still keep working but they will be removed in the next major release.

The new configuration format aims to drastically simplify the configuration of a Custom Application. In addition, it also strives to make the configuration process less error prone. To achieve this, the new configuration file is backed by a JSON schema that is shipped together with the new package. The configuration file is then validated against the JSON schema.

Furthermore, the new configuration process tries to infer as much information as possible to reduce the amount of required fields.

Recently we introduced a new host naming scheme for the commercetools APIs, including the Merchant Center, to increase region and cloud provider transparency.

While the previous hostnames such as *.sphere.io (Google Cloud, Belgium), *.commercetools.com (Google Cloud, Belgium), and *.commercetools.co (Google Cloud, Iowa) continue to be operational, we strongly recommend to migrate to the new hostname structure.

~~In regards to Custom Applications, the runtime configuration needs to be updated to support both the new and the legacy hostnames to allow users to log in with the new Merchant Center hostname, and to be backwards compatible with the legacy hostnames.~~

If you are using the [new application config file][/development/application-config], you can ignore the migration steps as the hostnames are automatically configured.

Here are the steps to take.