Integrate a dedicated frontend-build

[joerghoh]

it would be very benefical to have a dedicated frontend-build process integrated into the archetype. Nowadays webpack, gulp or other tools are popular among frontend developers, but the integration of their work is not forseen here.

We should create a frontend-module which uses the maven-frontend-plugin to run the build and then copies the result into a standard AEM clientlibrary for consumption. Of course this can only act as an example how the integration can be done, for real usecases it can and probably has to be adapted. But at the moment I don't see any integration being documented either here or on the Adobe website, which has gained relevance.

[gabrielwalt]

Great point, I agree. I tracked this internally with CQ-4252883.

[joerghoh]

A good example can be found at https://blogs.perficient.com/digexplatforms/2016/06/30/using-frontend-technologies-like-node-grunt-and-sass-with-aem/

[jbharrell]

@gabrielwalt has this been started yet? We've recently implemented this for a project and would like to pick this up if it's not already started internally.

Thanks!

[bpauli]

@jbharrell we are looking forward for your PR! Can you provide an ETA so we can plan our review task?

Thanks!

[jbharrell]

@bpauli I think we'll try to target having this ready in about 3 weeks PR will be coming from @iCiDIGITAL / @jbmatheson

[vladbailescu]

@jbharrell / @iCiDIGITAL / @jbmatheson, we're preparing to release version 18 of the archetype next week. Do you think you will be able to send a PR soon or will we move this to a future milestone? Thanks!

[jbharrell]

@vladbailescu We're close, but I think we should target release 19.

[jbharrell]

@vladbailescu @bpauli we've opened #185 for this. We've also filled out (signed) the CLA, but it doesn't seem to be getting picked up.

@jbmatheson

[godanny86]

Awesome work @jbharrell , @jbmatheson, @iCiDIGITAL on PR #185!

One question I'd like to raise is if it makes sense to include the FE build tools and source inside the ui.apps module? Why not introduce a new maven module, i.e ui.fed or something?, dedicated just to front end code, that deploys only the final compiled CSS and JS into AEM using aem-clientlib-generator. The approach could be similar to the integration used in the SPA Project archetype

I understand that traditionally Component-specific client-libraries have been maintained beneath the component itself in ui.apps. This makes it clear as to what component the CSS/JS apply to and for AEM developers they can modify other areas of the component (HTL, dialogs) in the same location.

Here are my arguments for introducing a new maven module to archetype:

• Scale better for larger projects since it will be easier to introduce Front End Developers (with no AEM experience) to work with a dedicated front-end project that just outputs CSS and JS. Having the webpack/node js project inside ui.apps, essentially forces the FED to understand how AEM works.
• With the emphasis on Core Components + Component Style System, there should be fewer components, leading to less AEM component development (HTL + dialogs) and more "theming" with CSS/JS alone. A dedicated FED module will be much easier to incorporate CSS/JS produced by an external agency
• With a good folder naming convention, it can be clear what components the CSS/JS apply to, i.e https://github.com/adobe/aem-core-wcm-components/tree/master/examples/src/content/jcr_root/apps/core-components-examples/clientlibs/clientlib-themes/core-components-clean/styles/components
• Very clear distinction between what file types can be compiled/processed by AEM Clientlibraries. I'm a little uncomfortable seeing .scss and .ts files deployed in CRXDE-Lite
• Already have a tried and true model to follow from the SPA Editor Archetype

TLDR - let's consider introducing a new maven module dedicated just for FED work that deploys compiled CSS/JS into AEM using aem-clientlib-generator similar to the integration used in the SPA Project archetype. Curious to get other's thoughts / point out areas i'm overlooking ;)

[jbmatheson]

@godanny86 - These are all great points! I completely agree that decoupling the source code from the ui.apps (and AEM in general) makes a lot of sense. The effort around this should not be difficult to do, though it will take some to shift the source over to its own folder and modify the archetype filter.

The SPA Editor Archetype is a full FE iteration "next step" to this archetype. I think my archetype is a great "hybrid" that leverages the best of both sides. Having said that, I definitely want to align it as much with the SPA Editor archetype as much as possible. The idea of a separate module was not lost on me but I wanted to hear feedback before I felt comfortable moving towards that model.

Great feedback! Thank you.

@jbharrell

[ghenzler]

I'm also in favour of a separate maven module for this - apart from the reasons already given by @godanny86 I would add that incremental maven builds in CI/CD also benefit from a separate maven module (e.g. one-file change in FE => only FE is built, change in HTL => only content package is built)

[bstopp]

I have to disagree with the separation of the FE code from the AEM code. This separation perpetuates the disconnect and 'hand-over' requirement from FE→ "AEM" devs.

The FE code should exist in the same AEM source that it affects - the FEDs should be concerned about their impacts to the Components & Templates, not separated. The FED should validate against the AEM instance, not outside it.

Must the FED know how to manage AEM, so they can perform their tests? No. This is the problem we should solve, not how to continue to keep the developers separated. This only perpetuates project churn and reduced velocity.

[thinkstainless]

While many outside agencies do prefer a standalone FED code base, for ADOBE best practices, an FED should be working within an AEM environment. Each customer specific FED process is going to be unique, which I feel cannot be built into the archetype. There are 3 workflows I see with AEM Front-end development:

1. Styles for using core components (prioritized)
2. Custom component development
3. Front-end hand-off from outside AEM (de-prioritized, requires custom workflows)

As Bryan mentioned as well, validation issues come up – UI defects being the hardest to track across a codebase outside AEM. Front-end has been too "over the wall" in the past, and with certain AEM features that are dependent on specific front-end code structures, the need for a more integrated process is more prevalent.

[jbmatheson]

@thinkstainless - I completely agree with you assessment that FEDs need to be working within the AEM environment. I believe at the core they are AEM developers first and FEDs second. However, AEM does not have any automated code quality checks integrated. Can it compile Less? Yes. Can it lint Less against best practices, auto-prefix in order to minimize cross-browser issues, normalize in post to boost performance? No. The same is true for JS. Typescript allows strict-typing which greatly reduces production errors due to Javascript's looseness.

The nature of this build is purely to reduce the load on leads and peers when it comes to code reviews and knowledge stop gaps when pushing code that will make it to production. It is meant to allow devs to work within the AEM space, natively, yet know that there are measures in place to protect the code. This is not merely about UI defects. It is more about keeping quality of code at a maximum while not deviating from the AEM environment to do so. That's why I feel this has a perfect place in an AEM archetype.

The workflow in the build is meant to be agnostic and high customizable. A team can easily run the archetype and modify the workflow anyway they see fits, adding/removing any features that are there within.

[godanny86]

Agree with @bstopp and @thinkstainless that FEDs should absolutely be developing and testing their code against an AEM instance. The intention of the feature is not to encourage "over the wall" thinking but rather find a way to allow FED to use the latest and greatest tools that are streamlined into an overall AEM build process. As @jbmatheson mentions, the archetype is just a jumping-off point, I believe the module will be optional when generating a new project and projects, if they decide to include it can modify the workflow as they see fit...

[ghenzler]

I have to disagree with the separation of the FE code from the AEM code

@bstopp I think the discussion was never about separating the code - it's clear that this is good practice (having FE and AEM code in the same repo to allow for pull requests that contain all code). Also it is clear that FE Devs should test against an AEM instance.

@godanny86 and my point was just that it's a lot better to separate FE and BE code into separate maven modules (for enterprise projects this scales a lot better). So the sub module ui.frontend as introduced in #205 is a great way forward!