.front-commerce.js

The .front-commerce.js configuration file at the root of a Front-Commerce project is the main entrypoint defining how an application behaves.

From this definition, Front-Commerce will initialize and register the different pieces composing your application.

name

The application name.

module.exports = {
  name: "ACME shop"
  // […]
};

This name is used for Developer Experience only and is not aimed at appearing in the theme or any website user message.

It is for instance used as title in the Storybook design system.

url

The project URL.

module.exports = {
  // […]
  url: "https://github.com/acme/shop/"
  // […]
};

This name is used for Developer Experience only and is not aimed at appearing in the theme or any website user message. You may thus use it to redirect to your staging instance, or project management tool for instance.

It is for instance used as link target for the name in the Storybook design system.

Use the FRONT_COMMERCE_URL environment variable to configure the URL used to access to your application.

modules

A list of path to Front-Commerce modules to register in your application.

module.exports = {
  // […]
  modules: ["./acme-common", "./src", "./winter", "./christmas"]
  // […]
};

Each module can contain client code to extend the theme, and server code to add custom server endpoints.

Front-Commerce modules are registered in the order they appear in this list. The default Front-Commerce theme will always be registered first and must not appear in this list.

In the above example, a component/Foo component would be resolved according to theme overrides in the following order (the first existing one would be used):

  1. ./christmas/component/Foo
  2. ./winter/component/Foo
  3. ./src/component/Foo
  4. ./acme-common/component/Foo
  5. front-commerce/src/web/theme/component/Foo

serverModules

A list of objects describing GraphQL modules to register in your application. GraphQL modules allows you to extend the GraphQL schema.

module.exports = {
  // […]
  serverModules: [
    { name: "FrontCommerceCore", path: "server/modules/front-commerce-core" },
    { name: "Magento2", path: "server/modules/magento2" }
  ]
  // […]
};

Each object must be composed of the properties below:

  • name: unique key that must be unique across the serverModules list. It is a temporary name that is used during a code generation step and has no other usage in the application. Do not worry about it, it will be deprecated in a near future: see #179 for further information.

  • path: must be a path to the GraphQL module definition file

GraphQL modules will be loaded according to the dependencies declared in their respective definitions. The order in the serverModules list should NOT be relied on for dependency management.

As of the latest release, Front-Commerce’s provides the following GraphQL modules (or meta-modules):

  • server/modules/front-commerce-core: core features of Front-Commerce.
  • server/modules/magento2 (meta module): Magento2 GraphQL modules to use Front-Commerce with all Magento2 supported features. Register single sub-modules explicitely if you only need a subset of features.
  • Front-Commerce’s embedded payment modules:
    • server/modules/payment-ogone: Ogone payment platform.
    • server/modules/payment-paypal: PayPal payment platform.
    • server/modules/payment-payzen: PayZen payment platform.

webModules

A list of objects describing the web modules to register in your application. Web modules allow you to register new routes in your application by using the filesystem. In the long run, it will be the main entrypoint to inject code through extension points in Front-Commerce.

module.exports = {
  // […]
  webModules: [
    { name: "FrontCommerce", path: "front-commerce/src/web" },
    { name: "Magento2", path: "./src/web" }
  ]
  // […]
};

Each object must be composed of the properties below:

  • name: unique key that must be unique across the webModules list. It is a temporary name that is used during a code generation step and has no other usage than debugging.

  • path: must be a path to the web module definition file, which is for now an empty js file. In the long run, it will allow you to define the extensions you are willing to support. In practice, we’re using require.resolve(webModule.path) which will check for a file using node’s resolver. This is why in most case, we are writing src/web but leaving aside index.js.

Web modules priority is defined by the order you are setting in the webModules array. The later, the more important.

The only functionality relying on webModules currently is the Routing. You can refer to the following pages for more information:

styleguidePaths

Default value: [ /.*.story.js$/ ]

A list of regexes that match the Storybook stories you want to use in your styleguide, so you can only display relevant stories in your Design System.

module.exports = {
  // […]
  styleguidePaths: [
    /.?\/components\/atoms\/Button\/.*.story.js$/,
    /.?\/components\/atoms\/Typography\/.*.story.js$/,
    /.?\/components\/molecules\/.*.story.js$/,
    /.?\/(pages|modules)\/.*.story.js$/
  ]
  // […]
};
Stories matching this pattern will be fetched across the web/theme folder of every Front-Commerce modules defined in the .front-commerce.js file.

build

An object containing configurations for your build pipeline.

build.include

Allows you to define which files should be parsed by webpack. This is especially useful when you have some library which uses javascript features not yet supported by the browsers you support.

You can either set it to:

  • an array of paths
  • a function which will allow you to transform the default include list by adding/removing the paths you need. It should return an array of paths.

Each path must be absolute. One way to do so is to use the following method:

const path = require("path");

module.exports = {
  build: {
    include: [
      path.dirname(require.resolve("react-intl/package.json")),
    ]
  }
}
Edit on GitHub