Dynamic import importing css file in production build

[Jdruwe]

I found your repo and was really interested into your implementation as we are also working with AEM and looking into Vite. One thing I am wondering is how you would handle a css import within dynamically imported javascript files.
I've created a test setup on my local machine where the manifest looks like this:

{
  "src/main.ts": {
    "file": "js/bundle.js",
    "src": "src/main.ts",
    "isEntry": true,
    "dynamicImports": [
      "src/other-module.ts"
    ],
    "css": [
      "css/bundle.css"
    ]
  },
  "src/other-module.ts": {
    "file": "chunks/other-module.73a4d6e6.js",
    "src": "src/other-module.ts",
    "isDynamicEntry": true,
    "css": [
      "css/other-module.css"
    ]
  }
}

The include of the actual files:

<script type="module" crossorigin src="/etc.clientlibs/project/clientlibs/clientlib/resources/js/bundle.js"></script>
<link rel="stylesheet" href="/etc.clientlibs/project/clientlibs/clientlib/resources/css/bundle.css">

When I click a button the chunks/other-module.73a4d6e6.js is dynamically imported but it seems like the css (css/other-module.css) is not included.

At https://www.aemvite.dev/guide/front-end/vite/#source-structure I've read the following:

Where your inputs come from isn't important as Vite simply consumes anything you provide to it. It is, however, recommended that you consider your main website CSS and JavaScript separate entries.

Do you recommend that approach because of the issue that I described above so that all css is included within a single file and no css will ever be included from within javascript files?

[Jdruwe]

Also I just saw something interesting. When there is no aemViteImportRewriter plugin being used the output in my bundle.js files is:

document.getElementById("viteButton").addEventListener("click", () => {
  m(
    () => import("../chunks/other-module.7198e493.js"),
    [
      "core.header/resources/chunks/other-module.7198e493.js",
      "core.header/resources/css/other-module.css"
    ]
  ).then((i) => {
    console.log(">>> Other module was loaded!");
  });
});

When I enable the plugin the output is:

document.getElementById("viteButton").addEventListener("click", () => {
  m(() => import("/etc.clientlibs/aem-vite-demo/clientlibs/core.header/resources/chunks/other-module.7198e493.js"), []).then(i => {
    console.log(">>> Other module was loaded!")
  })
});

As you can see the array is now empty behind other-module.7198e493.jsresulting in no css being imported. Do you have any idea why this is happening?

[cshawaus]

This issue can be tracked via aem-vite/import-rewriter#1

[cshawaus]

@Jdruwe I have released v4.0.0 of the import-rewriter npm package which resolves the import array becoming empty on transformations. This new version requires you to set the base option in your Vite config to your AEM ClientLib proxy path and to remove any hard-coded ClientLib proxy path from the output paths.

[cshawaus]

Hi @Jdruwe,

Apologies for the delay in replying. I will answer your first post first.

When I initially built AEM Vite I noticed that CSS behaved differently when customising the rollup options but didn't experience the same issue when using VIte standalone. For the projects that I work on daily I also noticed that CSS doesn't get extracted from the JS outputs when it should be and I still haven't found an explanation for this behaviour.

For now, keeping CSS as a separate entry works fine for my needs but I'm happy to go back and review this in the hope that things work better after some Vite/rollup releases.

As for your second question, I will raise an issue for this in the https://github.com/aem-vite/import-rewriter repo as I imagine the rewrite is changing Vite's transform behaviour which is not something I'd expect it to do.

[cshawaus]

I should have clarified, yes, just production builds. I also think our approaches are different as your example repo is focused on emulating what Vite does whereas AEM Vite is focused on using OOTB features within AEM. Here is the (my observations) problem in a nutshell...

Assuming we are just using AEMaaCS and not AEM standalone we have access to long-cache support using HTML Library Manager to generate our ClientLib outputs. This approach enables AEM Vite to engage itself with features that are complex but useful for the majority of client projects.

With this knowledge in mind, let's understand what AEM Vite is doing when generating script tags.

<script src="/etc.clientlibs/project_name/clientlibs/clientlib_name.js" type="module"></script>

The key takeaway from this example is that HTML Library Manager is responsible for generating this path which is taking our inputs from js.txt in our ClientLib. The underpinning implementation generates the content of this path dynamically using file I/O operations that are stored directly in the filesystem. There are benefits to this which include:

• Debugging
• Minification via yui or gcc
• Max age header configuration
• Processors for JS and CSS
• Caching

This all matters because when Adobe engages with clients they explain such capabilities and that is a foundational part of AEM Vite. But enough context, let's see the real problem. Let's imagine that our entry file in Vite is called main.ts which outputs to main.js. Along with it, we have a dynamic module called dynamic.ts that we're importing only when a condition is met.

With this in mind, let's see how the HTTP request lifecycle will occur.

1. Our ClientLib is loaded from /etc.clientlibs/project_name/clientlibs/clientlib_name.js
2. Within main.ts our condition is met and dynamic.ts is loaded via Vite's dynamic module loader
3. dynamic.ts has a reference to a function that was compiled into main.ts, this results in our import path being: ../js/main.js

Why this is a major problem for JavaScript (let alone ESM) is our browser will load main.js separately to /[...]/clientlib_name.js which ends up with a duplicated version of what was already loaded. AEM Vite's import rewriter solves this problem by converting import references such as ../js/main.js to fully qualified ClientLib proxy paths; eliminating the problem altogether.

In essence, the import within dynamic.ts file now attempts the below:

import { /* imports */ } from '/etc.clientlibs/project_name/clientlibs/clientlib_name.js';

This also applies to other imports too but are treated just as imports whereas main.js is special because it is our entry file.

TL;DR;
By following the OOTB conventions AEM provides we have the ability to use HTML Library Manager to its fullest potential rather than relying on Vite's injection strategy.

This is by no means an easy choice to make for AEM Vite as my initial idea was to rely solely on the mainfest.json file and inject entries automatically but it in itself has more challenges to overcome before it could become a reality.

[cshawaus]

I forgot to mention some key reasons why ClientLibs are used versus just outputting some tags on a page.

1. AEM Vite is designed to listen for any and all Vite DevServer's running on your network (locally or via Docker)
2. It automatically strips out existing ClientLib tags for any defined categories
3. Front end developers aren't required to do anything within AEM, it is all transparent and the expectation of what AEM Vite generates aligns to CSS and JS being generated by Adobe Core Components for example
4. It aligns with Adobe's OOTB feature set enabling developers to receive support from Adobe if need be
5. Enables easy transitions from webpack

[Jdruwe]

We are indeed using a different approach, I am trying to do as much work before (minification, hashing...)

The output of my clientlib .context.xml is modified:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
          jcr:primaryType="cq:ClientLibraryFolder" categories="[aem-vite-demo.esmodule]"
          cssProcessor="[default:none,min:none]" jsProcessor="[default:none,min:none]" allowProxy="{Boolean}true"
          scripts="[/etc.clientlibs/aem-vite-demo/clientlibs/clientlib-esmodule/resources/js/app.405d9e8c.js]"
          preloads="[/etc.clientlibs/aem-vite-demo/clientlibs/clientlib-esmodule/resources/chunks/vendor.9c4555cf.js]"
          stylesheets="[/etc.clientlibs/aem-vite-demo/clientlibs/clientlib-esmodule/resources/css/app.6c6c8de1.css]"
          moduleIdentifier="vite"/>

I list all chunks in specific properties of the file allowing me to choose how to load each one of them. For example the preloads scripts will be converted into modulepreload links

<script type="module" crossorigin src="/etc.clientlibs/project/clientlibs/demo-clientlib/resources/js/index.112a5b59.js"></script>
<link rel="modulepreload" href="/etc.clientlibs/project/clientlibs/demo-clientlib/resources/chunks/vendor.3f6b5a88.js">
<link rel="stylesheet" href="/etc.clientlibs/project/clientlibs/demo-clientlib/resources/css/index.f46a2696.css">

The clientlib will never be referenced as in your example using: /etc.clientlibs/project_name/clientlibs/clientlib_name.js, there even is no js.txt or css.txt. All files live under /resources

[cshawaus]

Thanks for sharing this, really provides a great insight into keeping things simple.

My mind is thinking about version 3 of AEM Vite now to include this style of inclusion more dynamic using manifest.json and to build on what AEM Vite already does but enable this as a simple option, and the existing implementation as an advanced option.

It would be awesome once I get a beta release available if you would be kind enough to help test it as I agree that the approach you are taking is not only simpler but provides native support for all of what Vite has to offer and more.

[Jdruwe]

I would love to help out! Thank you for the amazing code + documentation, it helped me a lot to get started ;) Also, I created a npm package https://www.npmjs.com/package/@jeroendruwe/vite-aem-clientlib-generator which I used to copy alls those chunks generated by Vite, move them to the clientlib folder + generate all those clientlib properties based on the manifest.json. Might come in handy.