Customize Webpack configuration

Roadmap Card


We want to allow users to extend the Webpack configuration.

User Stories

As a Frontity developer
I want to customize the default Webpack configuration
so that I can use change the default configuration and add additional features

Possible solution

Use the frontity.config.js file where you can export a function that receives the current Webpack config object.

In Frotity, we have 3 different configs, one for the server, another for the es5 bundles and another for the es6 (“module”) bundles.

This function will be run 3 times, one for each target.

export const webpack = ({ config, mode, target }) => {
  // Change the publicPath.
  config.output.publicPath = "";

  // Add support for a new file type.
    test: /\.ext$/,
    loader: "some-loader"

  // Change devtool option for development mode.
  if (mode === "development") {
    config.devtool = "cheap-eval-source-map";

  // Add an alias for the server.
  if (target === "server") {
    config.resolve.alias["some-package"] = "other-package";

  // Add an external for the client (both es5 and module).
  if (target === "es5" || target === "module") {
    config.externals["some-package"] = "window.variable";

We should allow for frontity.config.js files in:

  • The root folder of the project: People can add configuration specific to their project.
  • Inside packages: Package developers can add configuration specific to their packages.

@mmczaplinski opened another FD but Babel configuration instead of Babel: Customize Babel configuration

Babel and Webpack configuration are generated exactly in the same way, so we should be able to add both features at the same time.

Let’s keep the conversation in this one.

3 posts were split to a new topic: Support for mp4 videos

I’ve read that Webpack has relative path aliasing baked in. My workflow breaks from the mars-theme example and nests files pretty deep and this is definitely something that could save a lot of headache.

resolve: {
  alias: {
     '@common': path.resolve(__dirname, ‘src/components/common/’),
     '@images': path.resolve(__dirname, ‘src/assets/images/’)
1 Like


I found to make Frontity support the module aliases, was by digging into the webpack-config of Frontity and making the change there (node_modules/@frontity/core/dist/src/config/webpack/resolve.js).

In order to automate this, I have added a postinstall-script to the package.json which manipulates this file.

    "postinstall": "node scripts/extend-frontity-aliases.js"

I created a file “scripts/extend-frontity-aliases.js”

// Make alias work for frontity
const fs = require("fs");
const path = require("path");

const alias = `Components: "${path.resolve(

const utils = `Utils: "${path.resolve(

const sampledata = `SampleData: "${path.resolve(__dirname, "../sampledata")}",`;

// Read the original file
const originalResolveJS = fs.readFileSync(

// Insert alias line
const lines = originalResolveJS.split("\n");
const index = lines.findIndex(line => line.includes("alias: {"));
lines.splice(index + 1, 0, alias);
lines.splice(index + 1, 0, utils);
lines.splice(index + 1, 0, sampledata);

// Write back modified file

:warning: This is a pretty extreme hack and I would not recommend moving forward with these custom aliases until Frontity supports e.g. extending its webpack config.

1 Like

Hey guys :slightly_smiling_face:

Yes, we are going to support customizing Webpack via a frontity.config.js file, but that may still take a while.

Regarding alias, my personal recommendation is to avoid them. We’ve used them in the past but they generate more problems than benefits when you need to import the code in someplace different, like for example unit testing the code or publishing the code in npm.


4 posts were split to a new topic: How to use Emotion Theming

4 posts were split to a new topic: Vercel and webp images

2 posts were merged into an existing topic: Integrating ThreeJS on Frontity

Maybe time to switch to 100x faster.