How Does Webpack Fit Into AEM?
To get you started with Webpack in AEM, we created an open source project that provides you with step-by-step instructions on how to integrate Webpack into AEM. It also includes a fully working Webpack configuration with some essential plugins: Check out AEM Webpack Example on Github.
The rest of this article addresses common questions regarding the structure of AEM projects, and we highlight some concepts that become possible thanks to the use of Webpack in AEM.
Where to put the Webpack configuration in AEM?
Generally speaking, the job of Webpack is to take a bunch of files, process them somehow, and output the result. In an AEM project, we configure Webpack outside of AEM’s jcr_root folder and output the resulting files (bundles) into a folder we call “webpack.bundles” within the jcr_root folder.[ps2id id=’1′ target=”/]
Those Webpack bundles can be used in different ways. Here are common scenarios:
- You can reference them in one or more AEM clientlibs and load those clientlibs on a page. This approach conforms with the “AEM-way” of doing things and is easy to get started with.
- You can directly load the bundled files on your page referencing “/etc/designs/webpack.bundles/components.bundle.js”, for example, meaning you don’t use clientlibs for your bundles.
- You can refine your Webpack configuration and utilize Code Splitting, a feature to split code into various bundles which can then be loaded on demand or in parallel.
How to run Webpack using Maven?
We’ve seen AEM projects where tools such as Webpack and Grunt are run in addition to Maven only, meaning developers run Webpack to build (mostly) front end code, then run Maven to build the rest of the project. That’s inconvenient and time-consuming, especially for deployment to multiple AEM servers and continuous integration. Just imagine your back end developer pulling the latest code and not seeing the latest CSS changes because he ran Maven but forgot about Webpack.
If Webpack is part of the Maven build process, it can be run in two ways:
- Run Webpack as part of Maven.
Note: If you want your back end developers or DevOps to be able to run Maven without Webpack, you can set up a separate Maven build profile that doesn’t run Webpack.
- Whenever code can be reused in at least two components, we abstract it into a generic module that then can be imported into each component.
- By extending the super component “AEM.Component” that is part of our AEM module, we inherit methods and properties that should be available across all components. In this case, our super component provides “this.element” and “this.props” from the HTML of each component. While “this.element” simply represents the component’s HTML, “this.props” is a shortcut to access all data attributes of the component.
How to add Bootstrap?
Our recommendation for including libraries such as Bootstrap is to include them with AEM’s ClientLibs and only run them through AEM’s preprocessors, not through Webpack. By keeping these libraries out of Webpack, you keep the build lean, you don’t increase Webpack’s processing time, and you avoid conflicts between the vendor library and your project-specific setup, such as ESLint rules. We added an example for Bootstrap to the project wiki.
Assuming you’re interested in using Webpack in AEM, you should check out AEM Webpack Example on Github. We regularly use it to kickstart new projects, and the above mentioned insights will help you to write better modular code in Adobe Experience Manager.
And by the way, you can also partner with us for your upcoming projects.
The content of this post was originally presented by Kevin Weber at the Adobe Experience Manager Meetup in San Francisco. Here are the slides: