Documentation AEM AEM Tutorials AEM Sites WKND Tutorials

Review the full-stack AEM project’s ‘ui.frontend’ module aem-full-stack-ui-frontent

Last update: Sun Mar 23 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

Applies to:
Experience Manager as a Cloud Service

CREATED FOR:

Intermediate
Developer
Admin

In, this chapter we review the development, deployment, and delivery of front-end artifacts of a full-stack AEM project, by focusing on the ‘ui.frontend’ module of the WKND Sites project.

Objectives objective

Understand the build and deployment flow of front-end artifacts in an AEM full-stack project
Review the AEM full-stack project’s ui.frontend module’s webpack configs
AEM client library (also know as clientlibs) generation process

Front-end deployment flow for AEM full-stack and Quick Site Creation projects

IMPORTANT

This video explains and demonstrates the front-end flow for both Full-Stack and Quick Site Creation projects to outline the subtle difference in the front-end resources build, deploy, and delivery model.

https://video.tv.adobe.com/v/3409344?quality=12&learn=on

Transcript

Before making changes to the AEM project, let’s have a high level recap of how frontend artifacts are developed, deployed and delivered within the context of the standard AEM project using AEM project archetype and AEM site template builder. In the standard AEM project, within UI Frontend Module, the frontend developer makes changes to CSS and JavaScript files based on the requirements. And during build time, the Webpack, ModuleBundler and Maven plugin turn these files into optimized client library files under UI Apps project. Based on your project deployment cycle, these changes are deployed to the AEM environment by running the full stack pipeline and as part of that, Maven and AEM ClientLibGenerator NPM module saves newly generated ClientLib files into the AEM repository under slash apps. Finally, these artifacts are delivered to web browsers as CSS and JavaScript files via uripads starting with slash etc.clientlibs and typically they are cached on CDN or dispatcher. And in the AEM Site Template Builder project, within the Theme module, the frontend developer makes changes to CSS and JavaScript files based on the requirements. And during build time, Parcel, the zero config build tool turns these files into optimized files. Similarly, based on your project deployment cycle, these changes are deployed to the AEM environment by running, this time, the frontend pipeline and as part of that, Parcel and AEM Site ThemeBuilder NPM module deploys the optimized frontend artifact package directly to the CDN and notifies AEM of package path hash value. Likewise, these artifacts are delivered to web browsers as CSS and JavaScript files but this time served from a different hostname starting with https colon slash slash static and your environment identifier. Alright, let’s move from theory to practical by quickly verifying the workings of these two projects on the AEM as a cloud service environment and using our famous AEM weekend site project and standard site template repositories. I have cloned the weekend public GitHub repository locally and pushed the code to my cloud services programs repository after adding the remote repository entry. And I have deployed the weekend site code and sample content by running full stack deploy to dev pipeline in Adobe Cloud Manager. As you can see, site CSS and JavaScript is delivered to the browser via slash etc dot client libhats. Likewise, using the latest AEM site template standard zip file, I have created a new site called weekend quick site and I have customized the light gray background theme after downloading the theme sources from AEM and pushing it to Adobe repo. And create and run of a new front end pipeline called front end weekend quick site deployed to dev. This time the site CSS and JavaScript are delivered to the browser via different hostname starting with https slash slash static and my program ID. Please note, this front end pipeline is specific to the weekend quick site as the name suggests and totally separate from our standard AEM weekend project which we will be creating soon.

Prerequisites prerequisites

Clone the AEM WKND Sites project
Built and deployed the cloned AEM WKND Sites project to AEM as a Cloud Service.

See the AEM WKND Site project README.md for more details.

AEM full-stack project front-end artifact flow flow-of-frontend-artifacts

Below is a high-level representation of the development, deployment, and delivery flow of the front-end artifacts in a full-stack AEM project.

Development, Deployment and Delivery of Front-End Artifacts

During the development phase, front-end changes like styling, and rebranding are carried out by updating the CSS, JS files from the ui.frontend/src/main/webpack folder. Then during build-time, the webpack module-bundler and maven plugin turn these files into optimized AEM clientlibs under ui.apps module.

Front-end changes are deployed to AEM as a Cloud Service environment when running the Full-stack pipeline in Cloud Manager.

The front-end resources are delivered to the web browsers via URI paths starting with /etc.clientlibs/, and are typically cached on AEM Dispatcher and CDN.

NOTE

Similarly, in the AEM Quick Site Creation Journey, the front-end changes are deployed to AEM as a Cloud Service environment by running the Front-End pipeline, see Set up Your Pipeline

Review webpack configs in the WKND Sites project development-frontend-webpack-clientlib

There are three webpack config files used to bundle the WKND sites front-end resources.

webpack.common - This contains the common configuration to instruct the WKND resource bundling and optimization. The output property tells where to emit the consolidated files (also known as JavaScript bundles, but not to be confused with AEM OSGi bundles) it creates. The default name is set to clientlib-site/js/[name].bundle.js.

code language-javascript
`... output: { filename: 'clientlib-site/js/[name].bundle.js', path: path.resolve(__dirname, 'dist') } ...`

webpack.dev.js contains the development configuration for the webpack-dev-serve and points to the HTML template to use. It also contains a proxy configuration to an AEM instance running on localhost:4502.

code language-javascript
`... devServer: { proxy: [{ context: ['/content', '/etc.clientlibs', '/libs'], target: 'http://localhost:4502', }], ...`

webpack.prod.js contains the production configuration and uses the plugins to transform the development files into optimized bundles.

code language-javascript
`... module.exports = merge(common, { mode: 'production', optimization: { minimize: true, minimizer: [ new TerserPlugin(), new CssMinimizerPlugin({ ...}) } ...`

The bundled resources are moved to the ui.apps module using aem-clientlib-generator plugin, using the configuration managed in the clientlib.config.js file.

    ...
    const BUILD_DIR = path.join(__dirname, 'dist');
    const CLIENTLIB_DIR = path.join(
    __dirname,
    '..',
    'ui.apps',
    'src',
    'main',
    'content',
    'jcr_root',
    'apps',
    'wknd',
    'clientlibs'
    );
    ...

The frontend-maven-plugin from ui.frontend/pom.xml orchestrates webpack bundling and clientlib generation during AEM project build.

$ mvn clean install -PautoInstallSinglePackage

Deployment to AEM as a Cloud Service deployment-frontend-aemaacs

The Full-stack pipeline deploys these changes to an AEM as a Cloud Service environment.

Delivery from AEM as a Cloud Service delivery-frontend-aemaacs

The front-end resources deployed via the full-stack pipeline are delivered from the AEM Site to web browsers as /etc.clientlibs files. You can verify this by visiting the publicly hosted WKND site and viewing source of the webpage.

    ....
    <link rel="stylesheet" href="/etc.clientlibs/wknd/clientlibs/clientlib-site.lc-181cd4102f7f49aa30eea548a7715c31-lc.min.css" type="text/css">

    ...

    <script async src="/etc.clientlibs/wknd/clientlibs/clientlib-site.lc-d4e7c03fe5c6a405a23b3ca1cc3dcd3d-lc.min.js"></script>
    ....

Congratulations! congratulations

Congratulations, you reviewed the full-stack project’s ui.frontend module

Next steps next-steps

In the next chapter, Update Project to use Front-end Pipeline, you will update the AEM WKND Sites Project to enable it for the front-end pipeline contract.

recommendation-more-help

b2a561c1-47c0-4182-b8c1-757a197484f9