commercetools / merchant-center-application-kit

Tools and components for developing Merchant Center Customizations 🛠

commercetools UI Application Kit 💅

✨ Mono-repository with tools and components for developing Merchant Center customizations 🛠

To help you developing Merchant Center customizations, be sure to check out our ui-kit components library.

Getting started

If you are developing a Merchant Center Custom Application, follow the Custom Applications getting started guide.

If you are developing a Merchant Center Custom View, follow the Custom Views getting started guide.

Developing application-kit packages

Install the dependencies (uses pnpm workspaces):

$ pnpm install

To run the tests:

$ pnpm run test

# or
$ pnpm run test --watch

Build the application bundles

$ pnpm build

# or
$ pnpm build:bundles:watch

Start the playground application:

Note that the playground application consumes the app-kit dependencies ES modules, which means you need to bundle the packages first. We recommend to bundle the packages in watch mode in one terminal process and start the playground app in another terminal process.

// Terminal process 1
$ pnpm build:watch

// Terminal process 2
$ pnpm playground:start

Documentation

Please look at the single packages in packages folder for documentation specific of each package.

Contributing

Contributions are welcomed. Please have a read at our contribution guidelines.

merchant-center-application-kit's Issues

Remove login pages from AppShell, use redirects

This is just for awareness.

We are working on implementing new sign in screens in its own application and therefore removing the login screens from the AppShell.

For development, the AppShell will perform a redirect to the login service.

Add throw if pinned deps changed functionality to app kit

In the MC-FE, we have a script that checks if certain pinned deps changed, and throws an invariant if they do. We should have a similar functionality here, and/or move that into a package in app kit

Expose project owner (organizationId) from ApplicationContext

Describe the bug
The <ApplicationContext> currently does not expose the owner of the project (a.k.a. the organizationId).

Expected behavior
The project exposed by the application context should contain a fiel ownerId.

Running i18n:build will override core.json messages

Describe the bug
Recently we introduced a step to sync en.json -> core.json #124
However, when running i18n:build, the core.json messages get overridden with the defaultMessage values.

Expected behavior
After running i18n:build only new messages should be added. If a message key already exists, it should not be changed.

Self contained styles

Current situation

UI Kit has made a lot of changes lately. One of those changes is changing out CSS is exported. It's moving away from exporting postcss modules.

Currently, app-kit is importing two css files from ui-kit, and applying those globally to the MC apps. Those files are grid.mod.css and reset.mod.css.

There is an open issue in UI-Kit about moving those styles inline here.

Here is where those styles are both applied globally.

Next steps

• Consume css variables from UI-Kit in merchant-center-application-kit
• Move reset.mod.css into merchant-center-application-kit
• Possibly move the grid as well? Thoughts?

Fix rollup warnings when building packages

Summary

sentry package

cd packages/sentry
yarn build
yarn run v1.15.2
$ rimraf dist/**
$ npm run build:es && npm run build:cjs

> @commercetools-frontend/[email protected] build:es /Users/malcolmlaing/dev/merchant-center-application-kit/packages/sentry
> cross-env NODE_ENV=production rollup -c ../../rollup.config.js  -f es ./index.js -o ./dist/sentry.es.js

node-resolve: setting options.module is deprecated, please override options.mainFields instead
node-resolve: setting options.jsnext is deprecated, please override options.mainFields instead
node-resolve: setting options.main is deprecated, please override options.mainFields instead

./index.js → ./dist/sentry.es.js...
(!) Unresolved dependencies
https://rollupjs.org/guide/en#warning-treating-module-as-external-dependency
@babel/runtime-corejs3/core-js-stable/instance/concat (imported by sentry.js, sentry-user-tracker/sentry-user-tracker.js)
created ./dist/sentry.es.js in 904ms

> @commercetools-frontend/[email protected] build:cjs /Users/malcolmlaing/dev/merchant-center-application-kit/packages/sentry
> cross-env NODE_ENV=production rollup -c ../../rollup.config.js  -f cjs ./index.js -o ./dist/sentry.cjs.js

node-resolve: setting options.module is deprecated, please override options.mainFields instead
node-resolve: setting options.jsnext is deprecated, please override options.mainFields instead
node-resolve: setting options.main is deprecated, please override options.mainFields instead

./index.js → ./dist/sentry.cjs.js...
(!) Unresolved dependencies
https://rollupjs.org/guide/en#warning-treating-module-as-external-dependency
@babel/runtime-corejs3/core-js-stable/instance/concat (imported by sentry.js, sentry-user-tracker/sentry-user-tracker.js)
created ./dist/sentry.cjs.js in 917ms

application shell

Malcolms-Commercetools-MacBook-Pro:packages malcolmlaing$ cd application-shell
Malcolms-Commercetools-MacBook-Pro:application-shell malcolmlaing$ yarn build
yarn run v1.15.2
$ rimraf dist/** test-utils/**
$ npm run build:es && npm run build:cjs && npm run build:test-utils:cjs

> @commercetools-frontend/[email protected] build:es /Users/malcolmlaing/dev/merchant-center-application-kit/packages/application-shell
> cross-env NODE_ENV=production rollup -c ../../rollup.config.js  -f es ./index.js --dir ./dist --chunkFileNames application-shell-[name]-[hash].es.js --entryFileNames application-shell-[name].es.js

node-resolve: setting options.module is deprecated, please override options.mainFields instead
node-resolve: setting options.jsnext is deprecated, please override options.mainFields instead
node-resolve: setting options.main is deprecated, please override options.mainFields instead

./index.js → ./dist...
(!) Unresolved dependencies
https://rollupjs.org/guide/en#warning-treating-module-as-external-dependency
@babel/runtime-corejs3/core-js-stable/instance/includes (imported by src/configure-apollo.js, src/apollo-links/header-link.js, src/middleware/logger.js, src/components/requests-in-flight-loader/reducer.js, src/utils/select-project-key-from-url/select-project-key-from-url.js, src/components/project-data-locale/project-data-locale.js, src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/instance/concat (imported by src/configure-apollo.js, src/configure-store.js, src/components/application-shell-provider/application-shell-provider.js, src/components/setup-flop-flip-provider/setup-flop-flip-provider.js, src/components/handle-apollo-errors/handle-apollo-errors.js, src/components/inject-reducers/inject-reducers.js, src/components/requests-in-flight-loader/requests-in-flight-loader.js, src/components/requests-in-flight-loader/reducer.js, src/components/application-shell/application-shell.js, src/components/route-catch-all/route-catch-all.js, src/components/quick-access/index.js, ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js, src/components/project-data-locale/project-data-locale.js, src/components/gtm-user-tracker/gtm-user-tracker.js, src/components/redirector/redirector.js, src/components/quick-access/quick-access.js, src/components/project-container/project-container.js, src/components/navbar/navbar.js, src/components/quick-access/sub-commands.js, src/components/quick-access/utils.js, src/components/quick-access/create-commands.js, src/components/loading-placeholder/loading-placeholder.js, src/components/project-switcher/project-switcher.js, src/components/locale-switcher/locale-switcher.js, src/components/with-applications-menu/with-applications-menu.js, src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/instance/for-each (imported by src/middleware/hide-notifications.js, src/components/handle-apollo-errors/handle-apollo-errors.js, src/utils/gtm.js, src/components/quick-access/quick-access.js, ../../node_modules/@emotion/utils/dist/utils.esm.js, ../../node_modules/@emotion/sheet/dist/sheet.esm.js, ../../node_modules/@emotion/cache/dist/cache.esm.js)
@babel/runtime-corejs3/core-js-stable/reflect/has (imported by src/configure-store.js)
@babel/runtime-corejs3/core-js-stable/instance/reduce (imported by src/components/application-shell/application-shell.js, src/configure-store.js, src/components/fetch-project/fetch-project.js)
@babel/runtime-corejs3/core-js-stable/object/entries (imported by src/configure-store.js)
@babel/runtime-corejs3/core-js-stable/instance/starts-with (imported by src/middleware/logger.js, src/components/quick-access/quick-access.js, src/components/navbar/navbar.js, src/components/user-settings-menu/user-settings-menu.js)
@babel/runtime-corejs3/core-js-stable/instance/values (imported by src/middleware/sentry-tracking.js)
@babel/runtime-corejs3/core-js-stable/url (imported by src/utils/logger.js)
@babel/runtime-corejs3/core-js-stable/instance/filter (imported by src/components/performance-timing/measure-first-paint.js, src/utils/get-correlation-id/get-correlation-id.js, ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js, src/components/navbar/navbar.js, src/components/quick-access/create-commands.js, src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/map (imported by src/components/handle-apollo-errors/handle-apollo-errors.js)
@babel/runtime-corejs3/core-js-stable/instance/map (imported by src/components/performance-timing/measure-first-paint.js, src/components/quick-access/quick-access.js, src/components/navbar/navbar.js, src/components/quick-access/sub-commands.js, src/components/quick-access/create-commands.js, src/components/user-settings-menu/user-settings-menu.js, src/components/project-switcher/project-switcher.js, src/components/locale-switcher/locale-switcher.js, src/components/quick-access/butler/butler.js, ../../node_modules/@emotion/cache/dist/cache.esm.js, ../../node_modules/@emotion/serialize/dist/serialize.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/find (imported by src/components/application-shell/application-shell.js, src/components/navbar/navbar.js, src/components/quick-access/utils.js, src/components/user-settings-menu/user-settings-menu.js, src/components/project-switcher/project-switcher.js)
@babel/runtime-corejs3/core-js-stable/object/keys (imported by src/components/application-shell/application-shell.js, ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js)
@babel/runtime-corejs3/core-js-stable/array/is-array (imported by src/components/application-shell/application-shell.js, src/components/quick-access/quick-access.js, src/components/navbar/navbar.js, ../../node_modules/@emotion/core/dist/core.esm.js, src/components/with-applications-menu/with-applications-menu.js, src/components/quick-access/butler-command/butler-command.js, ../../node_modules/@emotion/serialize/dist/serialize.esm.js)
@babel/runtime-corejs3/core-js-stable/object/values (imported by src/apollo-links/header-link.js)
@babel/runtime-corejs3/core-js-stable/instance/reverse (imported by src/utils/gtm.js)
@babel/runtime-corejs3/core-js-stable/instance/index-of (imported by src/components/requests-in-flight-loader/reducer.js, ../../node_modules/@emotion/core/dist/core.esm.js, ../../node_modules/@emotion/serialize/dist/serialize.esm.js, ../../node_modules/@emotion/cache/node_modules/@emotion/stylis/dist/stylis.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/slice (imported by src/components/requests-in-flight-loader/reducer.js, ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js, src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/json/stringify (imported by src/components/quick-access/quick-access.js, src/components/performance-timing/actions.js, src/components/version-tracker/actions.js, src/components/quick-access/history.js)
@babel/runtime-corejs3/core-js-stable/object/create (imported by ../../node_modules/@emotion/core/dist/core.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/trim (imported by src/components/quick-access/quick-access.js, src/components/user-settings-menu/user-settings-menu.js, src/components/quick-access/butler/butler.js, ../../node_modules/@emotion/cache/node_modules/@emotion/stylis/dist/stylis.esm.js)
@babel/runtime-corejs3/core-js-stable/array/from (imported by src/components/navbar/navbar.js)
@babel/runtime-corejs3/core-js-stable/instance/every (imported by src/components/navbar/navbar.js)
@babel/runtime-corejs3/regenerator (imported by src/components/quick-access/quick-access.js, src/components/quick-access/create-commands.js)
@babel/runtime-corejs3/core-js-stable/instance/find-index (imported by src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/weak-map (imported by ../../node_modules/@emotion/weak-memoize/dist/weak-memoize.esm.js)
created ./dist in 6s

> @commercetools-frontend/[email protected] build:cjs /Users/malcolmlaing/dev/merchant-center-application-kit/packages/application-shell
> cross-env NODE_ENV=production rollup -c ../../rollup.config.js  -f cjs ./index.js --dir ./dist --chunkFileNames application-shell-[name]-[hash].cjs.js --entryFileNames application-shell-[name].cjs.js

node-resolve: setting options.module is deprecated, please override options.mainFields instead
node-resolve: setting options.jsnext is deprecated, please override options.mainFields instead
node-resolve: setting options.main is deprecated, please override options.mainFields instead

./index.js → ./dist...
(!) Unresolved dependencies
https://rollupjs.org/guide/en#warning-treating-module-as-external-dependency
@babel/runtime-corejs3/core-js-stable/instance/concat (imported by src/configure-apollo.js, src/configure-store.js, src/components/route-catch-all/route-catch-all.js, src/components/inject-reducers/inject-reducers.js, src/components/application-shell-provider/application-shell-provider.js, src/components/setup-flop-flip-provider/setup-flop-flip-provider.js, src/components/handle-apollo-errors/handle-apollo-errors.js, src/components/application-shell/application-shell.js, src/components/requests-in-flight-loader/requests-in-flight-loader.js, src/components/requests-in-flight-loader/reducer.js, src/components/quick-access/index.js, ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js, src/components/project-data-locale/project-data-locale.js, src/components/gtm-user-tracker/gtm-user-tracker.js, src/components/redirector/redirector.js, src/components/quick-access/quick-access.js, src/components/project-container/project-container.js, src/components/navbar/navbar.js, src/components/quick-access/utils.js, src/components/quick-access/sub-commands.js, src/components/quick-access/create-commands.js, src/components/project-switcher/project-switcher.js, src/components/loading-placeholder/loading-placeholder.js, src/components/locale-switcher/locale-switcher.js, src/components/with-applications-menu/with-applications-menu.js, src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/instance/includes (imported by src/configure-apollo.js, src/middleware/logger.js, src/apollo-links/header-link.js, src/utils/select-project-key-from-url/select-project-key-from-url.js, src/components/requests-in-flight-loader/reducer.js, src/components/project-data-locale/project-data-locale.js, src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/instance/reduce (imported by src/components/application-shell/application-shell.js, src/configure-store.js, src/components/fetch-project/fetch-project.js)
@babel/runtime-corejs3/core-js-stable/reflect/has (imported by src/configure-store.js)
@babel/runtime-corejs3/core-js-stable/object/entries (imported by src/configure-store.js)
@babel/runtime-corejs3/core-js-stable/url (imported by src/utils/logger.js)
@babel/runtime-corejs3/core-js-stable/instance/for-each (imported by src/middleware/hide-notifications.js, src/components/handle-apollo-errors/handle-apollo-errors.js, src/utils/gtm.js, src/components/quick-access/quick-access.js, ../../node_modules/@emotion/utils/dist/utils.esm.js, ../../node_modules/@emotion/sheet/dist/sheet.esm.js, ../../node_modules/@emotion/cache/dist/cache.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/starts-with (imported by src/middleware/logger.js, src/components/quick-access/quick-access.js, src/components/navbar/navbar.js, src/components/user-settings-menu/user-settings-menu.js)
@babel/runtime-corejs3/core-js-stable/instance/values (imported by src/middleware/sentry-tracking.js)
@babel/runtime-corejs3/core-js-stable/instance/map (imported by src/components/performance-timing/measure-first-paint.js, src/components/quick-access/quick-access.js, src/components/navbar/navbar.js, src/components/quick-access/sub-commands.js, src/components/quick-access/create-commands.js, src/components/project-switcher/project-switcher.js, src/components/user-settings-menu/user-settings-menu.js, src/components/locale-switcher/locale-switcher.js, src/components/quick-access/butler/butler.js, ../../node_modules/@emotion/cache/dist/cache.esm.js, ../../node_modules/@emotion/serialize/dist/serialize.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/filter (imported by src/utils/get-correlation-id/get-correlation-id.js, src/components/performance-timing/measure-first-paint.js, ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js, src/components/navbar/navbar.js, src/components/quick-access/create-commands.js, src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/map (imported by src/components/handle-apollo-errors/handle-apollo-errors.js)
@babel/runtime-corejs3/core-js-stable/instance/find (imported by src/components/application-shell/application-shell.js, src/components/navbar/navbar.js, src/components/quick-access/utils.js, src/components/project-switcher/project-switcher.js, src/components/user-settings-menu/user-settings-menu.js)
@babel/runtime-corejs3/core-js-stable/object/keys (imported by src/components/application-shell/application-shell.js, ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js)
@babel/runtime-corejs3/core-js-stable/array/is-array (imported by src/components/application-shell/application-shell.js, src/components/quick-access/quick-access.js, src/components/navbar/navbar.js, ../../node_modules/@emotion/core/dist/core.esm.js, src/components/with-applications-menu/with-applications-menu.js, src/components/quick-access/butler-command/butler-command.js, ../../node_modules/@emotion/serialize/dist/serialize.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/reverse (imported by src/utils/gtm.js)
@babel/runtime-corejs3/core-js-stable/instance/slice (imported by src/components/requests-in-flight-loader/reducer.js, ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js, src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/object/values (imported by src/apollo-links/header-link.js)
@babel/runtime-corejs3/core-js-stable/instance/index-of (imported by src/components/requests-in-flight-loader/reducer.js, ../../node_modules/@emotion/core/dist/core.esm.js, ../../node_modules/@emotion/serialize/dist/serialize.esm.js, ../../node_modules/@emotion/cache/node_modules/@emotion/stylis/dist/stylis.esm.js)
@babel/runtime-corejs3/core-js-stable/json/stringify (imported by src/components/performance-timing/actions.js, src/components/quick-access/quick-access.js, src/components/version-tracker/actions.js, src/components/quick-access/history.js)
@babel/runtime-corejs3/core-js-stable/instance/trim (imported by src/components/quick-access/quick-access.js, src/components/user-settings-menu/user-settings-menu.js, src/components/quick-access/butler/butler.js, ../../node_modules/@emotion/cache/node_modules/@emotion/stylis/dist/stylis.esm.js)
@babel/runtime-corejs3/core-js-stable/object/create (imported by ../../node_modules/@emotion/core/dist/core.esm.js)
@babel/runtime-corejs3/core-js-stable/array/from (imported by src/components/navbar/navbar.js)
@babel/runtime-corejs3/core-js-stable/instance/every (imported by src/components/navbar/navbar.js)
@babel/runtime-corejs3/regenerator (imported by src/components/quick-access/quick-access.js, src/components/quick-access/create-commands.js)
@babel/runtime-corejs3/core-js-stable/instance/find-index (imported by src/components/quick-access/butler/butler.js)
@babel/runtime-corejs3/core-js-stable/weak-map (imported by ../../node_modules/@emotion/weak-memoize/dist/weak-memoize.esm.js)
created ./dist in 5.7s

> @commercetools-frontend/[email protected] build:test-utils:cjs /Users/malcolmlaing/dev/merchant-center-application-kit/packages/application-shell
> cross-env NODE_ENV=development rollup -c ../../rollup.config.js  -f cjs ./src/test-utils/index.js --o ./test-utils/index.js

node-resolve: setting options.module is deprecated, please override options.mainFields instead
node-resolve: setting options.jsnext is deprecated, please override options.mainFields instead
node-resolve: setting options.main is deprecated, please override options.mainFields instead

./src/test-utils/index.js → ./test-utils/index.js...
(!) Unresolved dependencies
https://rollupjs.org/guide/en#warning-treating-module-as-external-dependency
@babel/runtime-corejs3/core-js-stable/instance/concat (imported by src/configure-store.js, src/configure-apollo.js, src/components/requests-in-flight-loader/requests-in-flight-loader.js, src/components/requests-in-flight-loader/reducer.js, ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js)
@babel/runtime-corejs3/core-js-stable/instance/includes (imported by src/middleware/logger.js, src/configure-apollo.js, src/apollo-links/header-link.js, src/components/requests-in-flight-loader/reducer.js, src/utils/select-project-key-from-url/select-project-key-from-url.js)
@babel/runtime-corejs3/core-js-stable/reflect/has (imported by src/configure-store.js)
@babel/runtime-corejs3/core-js-stable/instance/reduce (imported by src/configure-store.js)
@babel/runtime-corejs3/core-js-stable/object/entries (imported by src/configure-store.js)
@babel/runtime-corejs3/core-js-stable/instance/flags (imported by src/test-utils/test-utils.js)
@babel/runtime-corejs3/core-js-stable/instance/for-each (imported by src/middleware/hide-notifications.js, src/utils/gtm.js, ../../node_modules/@emotion/utils/dist/utils.esm.js, ../../node_modules/@emotion/sheet/dist/sheet.esm.js, ../../node_modules/@emotion/cache/dist/cache.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/starts-with (imported by src/middleware/logger.js)
@babel/runtime-corejs3/core-js-stable/instance/values (imported by src/middleware/sentry-tracking.js)
@babel/runtime-corejs3/core-js-stable/url (imported by src/utils/logger.js)
@babel/runtime-corejs3/core-js-stable/instance/index-of (imported by src/components/requests-in-flight-loader/reducer.js, ../../node_modules/@emotion/core/dist/core.esm.js, ../../node_modules/@emotion/serialize/dist/serialize.esm.js, ../../node_modules/@emotion/cache/node_modules/@emotion/stylis/dist/stylis.esm.js)
@babel/runtime-corejs3/core-js-stable/object/create (imported by ../../node_modules/@emotion/core/dist/core.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/filter (imported by ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js, src/utils/get-correlation-id/get-correlation-id.js)
@babel/runtime-corejs3/core-js-stable/instance/slice (imported by ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js, src/components/requests-in-flight-loader/reducer.js)
@babel/runtime-corejs3/core-js-stable/object/keys (imported by ../../node_modules/@commercetools/http-user-agent/dist/commercetools-http-user-agent.es.js)
@babel/runtime-corejs3/core-js-stable/array/is-array (imported by ../../node_modules/@emotion/core/dist/core.esm.js, ../../node_modules/@emotion/serialize/dist/serialize.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/reverse (imported by src/utils/gtm.js)
@babel/runtime-corejs3/core-js-stable/object/values (imported by src/apollo-links/header-link.js)
@babel/runtime-corejs3/core-js-stable/instance/map (imported by ../../node_modules/@emotion/cache/dist/cache.esm.js, ../../node_modules/@emotion/serialize/dist/serialize.esm.js)
@babel/runtime-corejs3/core-js-stable/weak-map (imported by ../../node_modules/@emotion/weak-memoize/dist/weak-memoize.esm.js)
@babel/runtime-corejs3/core-js-stable/instance/trim (imported by ../../node_modules/@emotion/cache/node_modules/@emotion/stylis/dist/stylis.esm.js)
(!) Unused external imports
get imported from external module '@commercetools-frontend/storage' but never used
created ./test-utils/index.js in 2.4s

Most other packages have warnings as well

[Testing] Add visual regression tests

Now that UI-Kit has a fairly mature visual regression testing setup, we should look into adding some basic visual regression tests to ApplicationShell. We can use a lot of the same setup that we did in UI-Kit, and we can use application-shell test-utils as well.

[Proposal] External/Remote Navbar Config

Motivation

Up until now we’ve been dealing with a static configuration for the navbar links, defined within the AppShell.
This allowed us to share the same config between all the applications, including custom applications.

However, having all the config for each application in one place has some disadvantages:

• Changes need to be released in app-kit, even while you are developing some new features (not released yet) that require a menu link
• All apps need to upgrade to the latest version to have the latest changes, including custom apps

I would say that those are becoming some very annoying problems that we should start dealing with.

Ideally, the AppShell should simply not have any hardcoded config and fetch it from a “common” place. This will allow to decouple the releasing of new changes in the Navbar from the AppShell and furthermore to ensure that all applications will get the same config on runtime, no matter which version of the AppShell is installed on each application.

So what is this “common” config and where does it come from?

I think that for starters, each application (the ones managed by us) should contain the Navbar config for their own routes. Then, during deployment, the config will be pushed to this “common” place, that contains all the configs of all applications.
This has the advantage of having the configs co-located to the application and being decoupled from the AppShell (as mentioned). Furthermore, changes to the config will be reflected immediately to all applications once deployed together with the application.

The main question I have is around the “common” place.
Eventually, the Navbar component will need to fetch this configs from an API endpoint or something.
I suppose we can have this config defined in our mc-settings API. Managing the updates to the config from the deployment though, might require some effort to sync the updates.
Another option might be to push the config to our storage bucket, as a static file. I think the problem here would be to properly sync/merge the configs from the different apps deployments.

I think this is the only open question we have to proceed with this approach.

Let me know what do you think and if you have concerns or suggestions about it.

---

Update: the final proposal is described here #37 (comment)

Installing starter template with npm fails to compile

The fix: #665 (comment)

---

Describe the bug
Starting the app with dependencies installed via npm causes webpack to fail to compile

To Reproduce
Install the application template starter with npm, then run npm start

Expected behavior
Installing the dependencies with npm should still work, as it does with yarn

Screenshots

Vertical alignment of "Ice cream" page

Describe the bug

[Tooling] Future improvements

While implementing a starter example #200 , we bumped into some issues that we would like to address in the near future. Those can be grouped into different topics:

👶 Easy to install starter example

The objective here is to have a basic example (like the one we have in examples/starter) that can be installed / bootstrapped with one single command.

I guess the classic example for that would be CRA.

$ npx create-mc-app my-app

Ideally we could create templates that you can install using create-react-app

$ npx create-react-app my-app \
  --scripts-version=@commercetools-frontend/mc-scripts \
  --template-starter 

For that to work we just need to restructure a bit the mc-scripts package and start supporting templates.

🧘‍♀️ Loosen dependency tooling

At the moment to develop an app, our own tooling is required, such as mc-scripts, mc-http-server. While this is per-se not a problem, it however forces users to use our opinionated environment like Webpack.

Ideally, people can choose whatever bundler or setup they like in order to develop the applications.

There are currently some problems with using different bundlers (e.g. parcel) as they don't fully support yet core-js@3, which causes several problems on production bundles.

Actions

Checklist of what needs to be done to achieve this goal

• add script to compile html #670

🚀 Deploy everywhere

At the moment, we recommend to use our mc-http-server as it comes with a couple of built-in features like injecting runtime stuff into the index.html.template, provides security headers, etc.

Until now, I found two use cases that won't work out of the box with our current setup:

• static website like Netlify: we need to provide some scripts or something that would help generating the necessary setup
• serverless functions like Now (v2): they run on Lambda functions, which means we can't just use a docker container but we need to upload specific files for each function

Actions

Checklist of what needs to be done to achieve this goal

• can deploy to Now v2 #670
  • documentation example
• can deploy to netlify
  • documentation example

Static types

Is your feature request related to a problem? Please describe.
Some of the packages (e.g. AppShell) have some pretty complex logic that often times causes small bugs to appear as it gets really tricky on finding out all the edge cases. This problem becomes more evident during refactorings.

Describe the solution you'd like
We should start adding static types to the application logic, with the goal of giving more confidence during refactorings and to also provide more helpful insights about the logic for new contributors.

Additional context
We can start with Flow, as it's more easy to integrate and we already use it in our backend services.

---

Migration progress:

• actions-global @emmenko #888
• application-components @emmenko #921
• application-shell (this should be the last one to migrate) @emmenko #1069
• application-shell-connectors @emmenko
• assets (not necessary)
• babel-preset-mc-app (not necessary)
• browser-history @emmenko #885
• constants @emmenko
• create-mc-app
• eslint-config-mc-app (not necessary)
• i18n @emmenko #774
• jest-preset-mc-app (not necessary)
• l10n @montezume #718
• mc-dev-authentication
• mc-html-template
• mc-http-server
• mc-scripts
• notifications @emmenko #884
• permissions @tdeekens #739
• react-notifications @emmenko #896
• sdk @emmenko #985
• sentry @emmenko
• storage @montezume #715
• url-utils @montezume #717

Expose version.js file from each package

Is your feature request related to a problem? Please describe.
As a consumer of the packages I want to import the version of the package within my application code, so that I can e.g. send the version of a package to an analytics or metrics service.

Describe the solution you'd like
Packages should expose a version.js file that can be imported by applications, containing the version of the given package.

Additional context
Read more info about this in #688

eslint-config-mc-app dep issue

There is a problem of the dependencies of eslint-config-mc-app when using the config in any project (observed in ui-kit):

 FAIL   eslint  src/components/inputs/money-input/dropdown-chevron.js
  ● Test suite failed to run

    Failed to load plugin import: Cannot find module 'eslint-plugin-import'
    Referenced from: /Users/nick/Sites/ui-kit/.eslintrc.yaml

      at Plugins.load (node_modules/eslint/lib/config/plugins.js:96:29)
          at Array.forEach (<anonymous>)
      at Plugins.loadAll (node_modules/eslint/lib/config/plugins.js:157:21)
      at loadFromDisk (node_modules/eslint/lib/config/config-file.js:506:35)
      at load (node_modules/eslint/lib/config/config-file.js:564:20)
      at configExtends.reduceRight (node_modules/eslint/lib/config/config-file.js:430:36)
          at Array.reduceRight (<anonymous>)
      at applyExtends (node_modules/eslint/lib/config/config-file.js:408

Note that this issue is not about eslint-plugin-import specifically, it just happens to be the first one to fail. If eslint-plugin-import is added as a dependency in ui-kit, then it fails with the next missing dependency eslint-plugin-jest and so on.

We are listing all dependencies as dependencies, but this does ensure/indicate that they need to be added to the main project.

Other ESLint config presets list list their dependencies as peerDependencies, and also als devDependencies (to ensure they are available during development of the config itself). See eslint-config-airbnb for example.

The recommended approach would be to move the necessary dependencies (all used by the config preset) to peerDependencys and to also add them as devDependencys for tests/development of eslint-config-mc-app itself.

@commercetools-frontend/jest-preset-mc-app > jest-plugin-filename > lodash dependency vulnerability

Describe the bug
When I run yarn audit, have a vulnerability in @commercetools-frontend/jest-preset-mc-app > jest-plugin-filename > lodash.

To Reproduce
Run yarn audit in version 12.0.0 or greater

Expected behavior
Pass audit without vulnerabilities

Screenshots

Remove/deprecate local store provider (legacy plugins)

Now that we have migrated the apps to not use globalAppState, we can finally get rid of the LocalStoreProvider. With that, there are also other things that we can/should remove that are not necessary anymore with the current structure (e.g. plugin concept, reducers, local middlewares).

I'll be start working on that this week.

Fail fast on CI

Current situation

If the tests fail on CI, the apps still build. See here for an example.

Ideal situation

If tests fail on CI, the command yarn build should not run.

Help / docs

travis-ci/travis-ci#1066

Adding UI components for building applications

Now that we started moving components into the new package @commercetools-frontend/application-components (#316), we can continue adding more components that will help building applications.

This issue is meant to show a priority list of the components that we want to move/add first.

Components should adhere to the same principles of components developed in ui-kit.

---

Storybook integration: #366

Maintenance pages

• PageNotFound (#316)
• ServicePageResponseLayout (#316)
• PageUnauthorized

Dialogs

• InfoDialog #367
• ConfirmationDialog #377
• FormDialog #399

Page layouts

These components should be implemented carefully, considering the use cases we've encountered so far. Most likely they are composed by lower-lever components that can be reused as well for special cases.

• TabPage
• InfoModalPage, FormModalPage, TabularModalPage #642
• ListPage

Controls

• Pagination
• WarnOnLeave

Support extension code for graphql errors

Is your feature request related to a problem? Please describe.
A recent spec change introduced an optional field extensions which is used by the graphql server to pass e.g. an error code.

The standard GraphQL error fields include message, path and locations. They are still available directly in the error object. Custom fields, like code, now can be found under extensions field.

We need to support this (our CTP API currently supports this as well, as well as our Settings API).

Describe the solution you'd like
Our API errors mapper should handle this case and try to handle it first by looking for extensions.code, otherwise falling back to code (which is what our CTP REST API uses).

Example of graphql error from our CTP graphql API:

{
  "data": null,
  "errors": [
    {
      "message": "'password' should not be empty.",
      "path": ["customerSignUp"],
      "locations": [{"line": 2, "column": 3}],
      "extensions": {
        "code": "InvalidOperation"
      }
    }
  ]
}

Example of graphql error from our Settings API:

{
  "errors": [
    {
      "message": "Some graphql error message",
      "locations": [{ "line": 1, "column": 1 }],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR"
      }
    }
  ]
}

[Idea] Have a package to share cypress plugins/commands

Is your feature request related to a problem? Please describe.
We can expose a cypress package @commercetools-frontend/cypress-mc-app to share some of our plugin setup/commands to test mc apps.

Ref: #427 (comment)

react-select v1 css should be applied by default

In applications that don't use react-select v1, it's weird to have to apply the css themselves. It would make more sense if it's done as part of the app kit.

I just refactored an app not to use react-select v1, and I tried to remove it, but broke the app as app kit is expecting it to be applied.

FormDialog problem showing data in select input

Describe the bug
I have a problem when render a FormDialog modal (i think its the same for all modals) when put a Select Input inside of it and display the data the info show inside of modal and I have to scroll down to see the values.

I try to hardcode .dialog-styles-mod_dialog-content__{dinamic} class with overflow: visibleand work as spected.

To Reproduce

1. Create a FormDialog
2. Put as children an input field.
3. Display the values and you can see it inside of modal and had to scroll down.

Expected behavior
See the dropdown values in front of modal.

Screenshots

Make ui-kit a peerDep (at least in application-shell)

Problem

After speaking to @Malcolm we noticed something which wasn’t obvious at first. As application-kit and all apps consume ui-kit there is a bit of a hassle when releasing new ui-kit versions: When there is a new ui-kit release, we need to upgrade app-kit to the new version. Then we need to release the new app-kit and then we need to upgrade app-kit and ui-kit in all applications. Quite some work we didn’t really expect :/

Let me try to explain the problem a bit more:

The packages use the app-shell. They also use ui-kit.

The app-shell uses the ui-kit.

If we release a new version of the ui-kit and update the applications only, then they will end up with both versions of the ui-kit in the application - as the app uses the new ui-kit version while the app-shell still uses the (pinned) old one.

Possible solution after talking to @emmenko:

I think it would work if we made ui-kit a peerDep in app-shell and specify a range. Then we only have the problem on breaking releases which is already better!

The task would be to make ui-kit a peer dep in application-shell (and possibly in other packages) and to specify a version range instead of a pinned version.

Consider moving CI to CircleCI

Our current CI flow is quite slow (~17min) as we are performing several sequential steps that take some time to finish.

If we move to CircleCI we can spread the jobs into parallel steps, which will decrease the time to execute a CI run.

Merchant Center Custom Application starter example wrong styles

Describe the bug
The styles are wrong in the Merchant Center Custom Application starter.

To Reproduce
$ npx @commercetools-frontend/create-mc-app@next my-new-custom-application-project --template starter

$ cd my-new-custom-application-project
$ yarn start

Expected behavior
The example starter init page should not break the styles.

Screenshots

Cannot start application locally in production mode

Describe the bug
With #289 we changed how the navigation menu is loaded. For instance, in production the menu configuration is fetched from a /api/graphql endpoint on the same domain of the frontend app, as a we have a proxy router between the LB and the applications.

In development though, we usually start the app directly, without the proxy router. To render the menu config of the specific application, we load the menu config from a local file, skipping the graphql request (as the endpoint does not exist).

However, when testing the production build locally like so:

NODE_ENV=production mc-http-server --csp=$(pwd)/csp.json --config=$(pwd)/env.json --use-local-assets

the application starts in "production" mode, triggering the non-existing graphql request.

Expected behavior
It should be possible to start the application locally in production mode without having the graphql request to error.

Additional context
One solution would be to check for the flag servedByProxy from the env.json, which usually indicates if the application runs behind the proxy or not.

A bit unrelated to the problem, but we might also want to look into manually putting the menu data into the cache when we don't fetch from the graphql endpoint, so that we can still make the graphql query which will only read from the cache.

Bundle with rollup

Same idea as for the ui-kit.

Be careful though that this is a monorepo. Have a look at flopflip to get an inspiration 🤓

Use different favicons for different environments

To facilitate the identification of the MC environment when having multiple browser tabs open, we can render different favicons (e.g.: dev, staging, production). This is particularly useful for people working and testing things across different environments.

Application starter template breaks on start

Describe the bug
Application starter template throws an error

To Reproduce
Steps to reproduce the behavior:

1. Install the template using create-mc-app
2. Start the application
3. The browser opens with an error

Expected behavior
The application starter should render without errors

[Proposal] Make playground import code from `src` instead of latest npm version.

Proposal

Playground will be a lot more useful if it can also be used when developing features for the application kit.

How?

Either use a babel plugin to change the imports to come from source whenever an import is coming from playground (such as babel-plugin-module-rewrite, or just rewrite the imports to read

import * as sdkActions from '../../src/packages/sdk'

Document API contract

We need to set up some ground rules about the process to introduce breaking changes (mostly from the MC API perspective) and some kind of "contract" between us and 3rd-party developers.

Here some thoughts on how we can go about that:

• custom applications are still under "beta" flag, which means that there might be some breaking changes along the way. We usually try to be as backwards compatible as possible but sometimes it's inevitable. As a consequence, the developers (and the customers) need to be aware of this.
  • before introducing breaking changes, we will try to do more thorough research by looking at our internal logs and metrics. We will then communicate a due date for the breaking change release, giving you (developers) time to adjust. I would say like between 1 week and 3 weeks, depending on the situation.
    • in some cases, where e.g. a breaking change only affects a few custom applications, we will try to communicate it directly with the developers/customers
  • we need to establish some sort of "last supported versions" where we will do the above mentioned steps. After that, it's not our responsibility anymore.
    • we support back to "x" versions of appkit dependencies (although it's not a good measure, because we don't have fixed planned releases, i.e. we could potentially release 3 majors versions within a week)
    • we support back to "x" weeks/months

---

Additional things:

• document deprecated fields of MC GraphQL API with a deadline about fields being supported

Transifex GitHub integration

Just for awareness.

There is a new feature to integrate transifex with github, and we have early access. We should try it out!

https://docs.transifex.com/integrations/transifex-github-integration

Fix postcss warnings for IE support

src/components/maintenance-page-layout/maintenance-page-layout.mod.css
3:3     ⚠  IE does not support align-items on grid containers. Try using align-self on child elements instead: .container > * { align-self: center } [postcss-preset-env]
4:3     ⚠  IE does not support justify-content on grid containers [postcss-preset-env]


src/components/maintenance-page-layout/maintenance-page-layout.mod.css
3:3     ⚠  IE does not support align-items on grid containers. Try using align-self on child elements instead: .maintenance-page-layout-mod_container__2eZnR > * { align-self: center } [postcss-preset-env]
4:3     ⚠  IE does not support justify-content on grid containers [postcss-preset-env]

Expose common messages

Is your feature request related to a problem? Please describe.
Check this issue: commercetools/ui-kit#249

Describe the solution you'd like
As proposed here we can simply expose some common messages for now.

We can expose those from the i18n package I suppose.

Describe alternatives you've considered
Have some "preset" components (e.g. <CancelButton> etc). However, we would like to try with only messages first.

CSP policy complains about webpack-dev-server hot reloading

Running the MC locally, you get a lot of messages like below, due to the webpack-dev-server's hot reloading breaking the CSP policy

Add notifications to ApplicationState

Now that we have the beautiful ApplicationStateProvider which serves as the-one-true-intersection-point between applications and and the AppShell, I think it might be a good idea to enhance it even more.

One of the things which is currently still inconvenient is showing notifications in the MC. I think we could move this to the ApplicationStateProvider as well.

Right now dispatching notifications works like this

import { connect } from 'react-redux';
import * as globalActions from '@commercetools-frontend/actions-global';

// your component
const SomeComponent = props => (
  <button
    onClick={() =>
      props.showNotification({
        kind: "success",
        domain: DOMAINS.SIDE,
        text: "hello"
      })
    }
  >
    Show Notification
  </button>
);

export default connect(
  null,
  { showNotification: globalActions.showNotification }
)(SomeComponent);

However this could get as simple as

const SomeComponent = props => (
  <GetApplicationState
    render={applicationState => (
      <button
        onClick={() =>
          applicationState.showNotification({
            kind: "success",
            domain: DOMAINS.SIDE,
            text: props.intl.formatMessage(messages.lineItemUpdated)
          })
        }
      >
        Show Notification
      </button>
    )}
  />
);

This would allow us to also test notifications dispatched by components more easily.

import SomeComponent from './some-component'
import { render, fireEvent } from '@commercetools-frontend/application-kit/test-utils'

it("should dispatch a notification when clicked", () => {
  const { getByText, notifications } = render(<SomeComponent />);
  fireEvent.click(getByText("Show Notification"));
  expect(notifications).toContainEqual({
    kind: "success",
    domain: DOMAINS.SIDE,
    text: "hello"
  });
});

Stagings and emotion source maps

Summary

Currently in our babel-preset-mc-app, and also in the babel preset for ui-kit, we remove source maps if the node_env is production.

More info about emotion source maps can be read here.

I think it's worthwhile to remove source maps in production. it leads to less data being sent down the wire to the user.

Problem

Some people use our staging environments for debugging the applications. I have talked to some designers who are used to being able to 'inspect element', and be able to change values. Now they are unable to do this.

Possible solution

Would it be feasible to have another node env? staging? And in this environment, ship the source maps? I guess it would lead to our circle environments have to do even more app building.

User language changes not propagated to intl locale

Describe the bug
When the language is changed via the dropdown in the navigation bar, the locale field in intl is not updated.

To Reproduce
Steps to reproduce the behavior:

1. In any view within the MC, change the language via the dropdown.
2. Inspect the intl provider (via props.intl in any component using the HoC)
3. Inspect the locale field of the intl provider.

Expected behavior
The locale field of the intl provider should be the same as the app language.

Screenshots
en language

de language

Additional context
The bug was discovered when attempting to format prices using intl.formatNumber. The method uses the locale stored internally within intl.

CSS in JS should be linted

Summary

Since the package application-components makes use of CSS in JS, it would make sense to add CSS linting to it.

This was added to ui-kit in this pull request

It should be not too difficult to get this setup for app kit as well. We need to make sure we resolve stylelint to the new version though 😆

Triggering `QuickAccess` programatically

The topic of being able to trigger QuickAccess has came up with regards to the new Welcome Screen.

The idea would be that, we can trigger QuickAccess on a button click, and when QuickAccess is triggered this way, it will display additional usage instructions like below

What would the best way doing this? I came up with a few ideas.

• Simply fire a keydown event through JavaScript with some sort of custom property, and if this custom property is present, QuickAccess renders with these additional instructions
• Provide an API for triggering QuickAccess programatically, perhaps through ApplicationContext.

Any other ideas?

Setup Gatsby for documentation website

We will start with a setup similar to commercetools/ui-kit#495

---

• #566
• #573
• #588
• #593
• #595

Enhance and move playground into a starter template

The idea is to:

• enhance the playground app (for managing state machines) to make it a more complete example of managing data in the UI
  • data fetching using rest (sdk)
  • list view and details view
  • basic form management
• move the playground into a starter template, so that people can actually download it and use it as a starter point

Furthermore, this would be really helpful for me to get feedback about the docs and the tooling.

Rewrite components tests to RTL

Just to keep track of it. Whoever wants to start rewriting tests for some of the components is free to do so.

Merchant Center Custom Application fetch external data

Describe the bug
I'm not sure if this is a bug, or a feature that is not available.
This is my question:
¿Is it possible to fetch external data inside the Application?
I'm developing the customer application in local and try to call an external API, but CSP Policy violation error is thrown.

[Tooling] Add script for checking pin dependencies

We should have the throw-if-pinned-dependency-version-changes.js script that we use in the MC FE in this repo as well and update the list accordingly.

favicon not showing

Describe the bug
Currently MC's favicon not showing on staging/production
To Reproduce
Steps to reproduce the behavior:

1. Go to MC in a browser that you don't normally use. or
2. Check the response of the favicon request in network tab

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Babel and rollup remove prop-types in production builds

Describe the bug

All packages/* are being built with Rollup while Babel gets a say in what transforms to apply. Whenever we build for production we remove prop-types from the artefact(s). This implies that no other consumer (always consuming a production build) receives prop-type warnings using any package. No prop-types warnings for any mc-app neither during local development, staging or production for any package from this repo.

To Reproduce

Given you build any or all packages
And you inspect the build output
Then no prop-types are part of any component

Root cause

The Babel config here is being run in "production mode" which triggers this condition:

isEnvProduction && [
  // Remove PropTypes from production build
  require('babel-plugin-transform-react-remove-prop-types').default,
  {
    removeImport: true,
  },
],

to remove prop-types. This is triggered by Rollup builds by e.g. the permissions package with

"build:es": "cross-env NODE_ENV=production rollup -c ../../rollup.config.js  -f es ./index.js -o ./dist/permissions.es.js",

The respective Babel config is shared between Rollup (library builds) and Webpack (application builds).

The crux

Not run library builds (all packages) in "production mode". The isEnvProduction in Babel seems to trigger:

1. Removal or prop-types
2. babel-preset-env building for the n-1 browser versions
   • This may sound like "oh wow, that's a modern target" but includes older IEs I believe

Given we do not want to run Babel again on our built assets when installed in apps (as they're in node_modules) we actually want to run those Babel transforms.

Maybe we want to remove prop-types removal from our default Babel config altogether and apply it additionally in our webpack config here only for production which is where prop-types should be removed.

Expected behavior

Likely prop-types should be part of the build artefact and then should be removed by the respective "application-level" build system. Moreover, prop-types are environment dependent. They're often intended on a staging environment (just for informative reasons) while being suppressed on production.

Additional context

This came up during #217 where tests failed with an error being thrown while the error disappeared when a build steps were run before testing. Then tests passed as prop-types are then removed.

Sorry for the wall but I wanted to document this. /cc @montezume and @emmenko as this seems up your interests.

Refactor `assets` package to contain files with semantic naming

Describe the change

The @commercetools-frontned/assets package currently contains assets with non semantic filenames. So files are called after where they are used ProjectSuspended.svg etc. This makes reuse hard as the filename already suggests a use case. Instead we could, as with icons in UIKIt, name files after what they are: Hourglass.svg for instance can be used for project suspension and pending initialization.

Follow ups

1. Come up with a clear naming policy with design /cc @filippobocik
2. Implement the change and document the breaking change

Add badges

It would be nice to add some badges (build status on CI, latest version on npm, ...).

[Proposal] Define CSP and Security Headers in MC Proxy, deprecate csp.json

This proposal is part of the tooling improvements in #214

Motivation

At the moment, using the mc-http-server to run an application in production will include security headers, such as CSP. The mc-http-server comes with a pre-defined configuration that can be extended using a csp.json file.

While this approach is perfectly fine, it has some drawbacks:

• security headers are defined within the mc-http-server and are not enforced by our production system
• people can choose to deploy the application in a different way, by not using the mc-http-server package, which results in a "loss" of the headers (unless the user explicitly defines them again)

To support those use cases, of developing applications using other tooling (e.g. parcel), we need to rethink a bit our approach and make it easier for people to have secured applications without much effort.

Proposal

Given that in production each application is served by our MC Proxy, we can define the security headers (including CSP) in the proxy server itself.

Local development

At the moment, the development server (webpack-dev-server) is configured to apply the security headers. In general, I find it useful to have that for development, because it's a setup that resembles production and it's useful to have the app secured.

So how should we deal with that and the MC proxy?

I suppose we could move the security headers config into a separate package, which can be used by both the MC Proxy and for whatever server is used for local development.

CSP for custom applications

Custom applications still need to extend the CSP based on the domains they are hosted and other possible external services used by the application.

I guess there are a couple of options that we can use to do so:

• extend the CSP config using custom HTTP headers (e.g. "x-mx-csp-script-src"="foo.com,bar.com")
• extend the CSP config as settings (where you register your applications in the MC)

Outcome

It should be possible to develop applications using different tooling and different ways to deploy them (even as static apps with e.g. Netlify) without worrying about security headers.