Add support for webpack dev server to inject in-memory build assets into AEM served pages

[prowner]

Expected Behaviour

Webpack dev server should proxy content pages from AEM and inject it's in-memory assets in the page. This way the dev server will create the bundles in memory. Webpack provisioned clientlibs should not be proxied.

For the ui.frontend.react, this requires rewiring the CRA Webpack config.

Actual Behaviour

Webpack dev server only proxies, but still requires a build to provision the clientlibs. Live reloading is not supported with watch.

Reproduce Scenario (including but not limited to)

Steps to Reproduce

Make a code change in ui.frontend. To see the changes on an AEM page, a Webpack build is required, then the clientlibs need to be built, and then the clientlibs need to be synced to the local instance.

Platform and Version

AEM

Sample Code that illustrates the problem

Logs taken while reproducing problem

[bpauli]

@robinalaerts1 Thank you for the hands up! May I ask you to create a PR for this enhancement?

[prowner]

@bpauli How do you get permission to push to this repo?

[soluml]

+1

We've actually modified our builds to do this. We have Webpack generate the assets, output the result as a aem-clientlib-generator config file, then generate the resulting clientlibs. Webpack is then aware of all clientlibs that should not be proxied. All other requests are proxied back to AEM. This allows for true HMR for all Webpack control assets and has definitely sped up development for us. We haven't tried this with the SPA editor configs but the same principles would apply to all three configs: React, Angular, and Generic.

[soluml]

@bpauli How do you get permission to push to this repo?

Fork this repo, make your changes in the develop branch, then PR back into this repo's develop branch.

[prowner]

@soluml any feedback on this approach?

[soluml]

So I haven't pulled this down to try it but just a few things I'm curious about looking at the PR changes:

1. Where does 'opp' come from on L26 in webpack.dev.js. Seems like something that should exist in a project variable?

2. webpack-dev-server includes http-proxy-middleware as a dependency. Could things be re-tooled a bit so there's a consistent proxying script across all three frontend folders?

3. I'd expect there to be a corresponding Angular update as well.

An aside:

One of the other things we've done at my agency that I like is leveraging Webpack to generate the aem-clientlib-generator config. As it stands currently, Webpack must generate consistent bundle names which limits the kinds of optimizations we can on said bundles. For example, I currently cannot optimize bundles to break apart if the size is >200kb. Effectively any dynamically generated clientlibs cannot be allowed. To solve for this, we added the assets-webpack-plugin. It generates a highly configurable file based off of assets produced by Webpack which means we can tune our optimization rules. We've customized ours to spit out a clientlib.config.js file. We've used this to optimize our code for HTTP/2 for example when we know a project is sitting behind a CDN that supports it.

This could obviously be tacked on later so it wouldn't preclude this PR from moving forward but it fit really nicely in our builds when we implemented HMR with our builds. More food for thought than anything!

Thanks for tackling this @robinalaerts1! HMR has given us a dramatic development speed increase and certainly brings Front-End Development on AEM into modernity.

[prowner]

So I haven't pulled this down to try it but just a few things I'm curious about looking at the PR changes:

1. Where does 'opp' come from on L26 in webpack.dev.js. Seems like something that should exist in a project variable?
2. webpack-dev-server includes http-proxy-middleware as a dependency. Could things be re-tooled a bit so there's a consistent proxying script across all three frontend folders?
3. I'd expect there to be a corresponding Angular update as well.

An aside:

One of the other things we've done at my agency that I like is leveraging Webpack to generate the aem-clientlib-generator config. As it stands currently, Webpack must generate consistent bundle names which limits the kinds of optimizations we can on said bundles. For example, I currently cannot optimize bundles to break apart if the size is >200kb. Effectively any dynamically generated clientlibs cannot be allowed. To solve for this, we added the assets-webpack-plugin. It generates a highly configurable file based off of assets produced by Webpack which means we can tune our optimization rules. We've customized ours to spit out a clientlib.config.js file. We've used this to optimize our code for HTTP/2 for example when we know a project is sitting behind a CDN that supports it.

This could obviously be tacked on later so it wouldn't preclude this PR from moving forward but it fit really nicely in our builds when we implemented HMR with our builds. More food for thought than anything!

Thanks for tackling this @robinalaerts1! HMR has given us a dramatic development speed increase and certainly brings Front-End Development on AEM into modernity.

1. Good catch, I've replaced this with a generic matcher
2. As this is the recommended approach by CRA, I think it's the most safe. I've also looked into doing it directly in the webpack config, but apparently CRA is not using the proxy config like a normal dev server.
3. Is this blocking? As I dont have any Angular setup (and not too much time)

Generating the clientlib.config.js would be a great enhancement. When I have more time I'm definitly looking into this.

[soluml]

Not a maintainer so I can't speak for whether or not that'd be blocking but unfortunately I think so. I only use React/General so it wouldn't be blocking for me :)