How to Work with Engine Logs in Local Development Environment

When working with fusion-cli locally, it’s important to be familiar with the key signals it outputs and how to navigate them when working on complex bundle codebases (where the log stream can be large).

Build completion message

Starting with Engine 4.0.5 and fusion-cli 2.2.0 releases, now fusion-cli prints a build-complete message when it’s done and ready to use:

fusion-webpack    |
fusion-webpack    |     .d8888b. 88d888b. .d8888b. dP.  .dP 88d888b.
fusion-webpack    |     88'  `88 88'  `88 88'  `""  `8bd8'  88'  `88
fusion-webpack    |     88.  .88 88       88.  ...  .d88b.  88.  .88
fusion-webpack    |     `88888P8 dP       `88888P' dP'  `dP 88Y888P'
fusion-webpack    |                                         88
fusion-webpack    |                                         dP
fusion-webpack    |
fusion-webpack    |     Webpack build completed in 19159 ms.
fusion-webpack    |
fusion-webpack    |     You can now view PageBuilder Editor in your browser:
fusion-webpack    |     http://localhost/pagebuilder/pages

Build timing messages

Along with build completion message, we introduced build timing messages. When Engine builds clients bundles, it does multiple step compilation to work on different part of the bundle at the same time.

fusion-cli now prints timings on both completion message and in each build step with step name. Client developers can now pin point which part of their bundle builds taking longer, and take specific actions to optimize build time.

Build steps

The steps below are all possible build timing outputs you may see in your command line.

Tip

Not all steps are required or have to run in your build; you may see a combination of some of these steps in your build process.

Build step name	What it means	What to expect
bundle-[js | hbs | jsx]-output-types	Compilation of output types	Each output type automatically becomes an entrypoint within the webpack config, so that the output can be optimized to only include components specific to that output type. Compilation performance (build speed) directly correlates with the number of output types in your bundle. When using multiple output types, you can optimize your build by using the fallback property to ensure that components are not unnecessarily included in your output types.
bundle-[js | hbs | jsx]-combinations-server	Compilation of the server-side components (layouts, features, chains)	This build step contains every component in the bundle and is likely to be the longest running webpack step.
bundle-jsx-combinations-client	Compilation of the client-side React bundle that is shipped to the browser	This build step is a subset of the server-side compilation, as static components will not be included in the client-side JS.
bundle-content-schemas	Compilation of content schemas	Fairly quick build time.
bundle-content-sources	Compilation of content sources	Fairly quick build time.
bundle-environment	Compilation for environment variables set within the bundle	Fairly quick build time.
bundle-i18n	Compilation for internationalization on components within the bundle	Fairly quick build time.
bundle-site-properties	Compilation for site properties within the bundle	Fairly quick build time.
bundle-styles	CSS compilation of styles within the bundle	Build time is dependent on the complexity of CSS within the bundle.
theme-properties	Only used by Themes 1.x.	N/A unless using Themes 1.x. Fairly quick build time.
engine-libraries	Engine-specific dependencies (admin.js, polyfill.js, preview.js, and react.js) to enable functionality within PageBuilder Editor.	Fairly quick build time.

How to work with large log output, to search and filter it?

When working with Engine in your local development environment, it’s important to watch and monitor your engine logs. Engine command line tool: fusion-cli will output. not only engine logs but also other docker containers outputs. These services altogether are orchestrated together to run engine locally. Depending on what your code does, these services output can be crowded and it can be difficult to navigate between them. There is a simple way to focus on just engine logs and be able to filter them with a regular expression search.

We suggest using a tool like dozzle that runs as a minimal, separate app in an additional container aside of your engine containers. Dozzle is a simple web application watch your docker logs (not just engine, but all running containers logs) and provide an easy web interface to work with.

Run dozzle with a simple command:

docker run --name dozzle -d --volume=/var/run/docker.sock:/var/run/docker.sock -p 8686:8080 amir20/dozzle:latest

Then open http://localhost:8686 in your browser.

Now you can select fusion-engine container to see all of engine, your console.log statements and more.

If you enabled debugging mode for fusion events, you can filter them and see events like server-side-render failures, content source calls, timing of content source executions, fusion-cache read and writes.

Being able to navigate your engine logs and filter them in dozzle can improve your troubleshooting process and debug issues faster.