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 towork 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.