feat: add extra dist folders control and generate clientlibs for SplitChunks

[infloent]

Description

• The solution It does not enforce any source folder structure
• It allows for a different source (less folder nesting) vs dist folder structure.

Currently source and dist folder structure must be mirrors.
Now a source folder can not contains more than one entrypoint file of type js or scss because of AEM requirement on the dist side where each clientlib needs it’s own folder with it's own .xml, .txt files.

This will fix this limitation and allow to have multiple entrypoints in the same source folder but generate extra dist folders as required for AEM clientlibs categories.

New options

All would default to false / []. Existing projects would be unaffected unless they opt in.

Filename-based dist folders (config.general)

Option	What it does
sourceKey: string or string[]	Match one or multiple source suffixes (e.g. 'clientlibs' or ['clientlibs', 'publishlibs', 'authorlibs'])
sourceKeyAsDistFolder: true	Promote the matched sourceKey suffix to a dist subfolder
fileNameDotSuffixesAsDistFolder: true	Promote dot-segments between name and sourceKey suffix to dist subfolders
excludeFileNameDotSuffixes: string[]	Opt specific values out of folder promotion. Supports exact strings and regular expressions (migration safety valve)

Split chunks clientlibs (config.clientlibs)

Option	What it does
generateSplitChunksClientlibs: true	Auto-generate .content.xml + js.txt for webpack splitChunks / runtimeChunk output folders

This would be independent of the filename-based flags above. checkChunk would also expose module.resource (the full file path including filename) to splitChunks cache group test functions, making it possible to also route files by name convention into dedicated chunk groups.

The idea

All files for a component live in one folder (not mandatory). One ls returns the complete picture of what it does and how it splits, useful for developers navigating the codebase and for AI tools that rely on directory context to understand component scope.

When an AI needs context to fix or extend a component, one directory read is enough instead of correlating multiple parallel trees, which means fewer tool calls and less context consumed.

With this options

sourceKey: ['clientlibs', 'publishlibs', 'authorlibs'],
sourceKeyAsDistFolder: true,
fileNameDotSuffixesAsDistFolder: true,
excludeFileNameDotSuffixes: ['clientlibs']

And this example source structure (not a requirement)

src/components/cmp/v1/cmp/
  cmp.main.publishlibs.js       ← The main cmp functionality
  cmp.main.publishlibs.scss     ← The default cmp styles
  cmp.main.authorlibs.js        ← The main cmp author functionality when needed
  cmp.main.authorlibs.scss.     ← The default cmp author styles overwrites
  cmp.layout1.publishlibs.scss  ← loaded only when needed based on cmp config
  cmp.layout1.authorlibs.scss   ← some layout/feature might need author css overwrites
  cmp.layout2.publishlibs.scss  ← loaded only when needed based on cmp config
  cmp.tracking.clientlibs.js    ← loaded if tracking is enabled
  cmp.dialog.clientlibs.js       ← loaded as extra clientlib in dialog
  cmp.dialog.clientlibs.scss     ← loaded as extra clientlib in dialog
  cmp.editor.clientlibs.scss     ← custom granite editor toolbars widgets

The generated dist structure will be:

dist/components/cmp/v1/cmp
  main/
    publishlibs/
      .content.xml
      js.txt
      css.txt
      cmp.bundle.js
      cmp.bundle.css
    authorlibs/
      .content.xml
      js.txt
      css.txt
      cmp.bundle.js
      cmp.bundle.css
  layout1/
    publishlibs/
      .content.xml
      css.txt
      cmp.layout1.bundle.css
    authorlibs/
      .content.xml
      css.txt
      cmp.layout1.bundle.css
  layout2/
    publishlibs/
      .content.xml
      css.txt
      cmp.layout2.bundle.css
  tracking/
    .content.xml
    js.txt
    cmp.tracking.bundle.js
  dialog/
    .content.xml
    js.txt
    css.txt
    cmp.dialog.bundle.js
    cmp.dialog.bundle.css
  editor/
    .content.xml
    css.txt
    cmp.editor.bundle.css

---

Related Issue

Fixes: Update chokidar usage to support v4 (glob patterns removal) -> as a prerequisite.

Fixes: Flexible source vs dist folders/clientlibs management

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• All new and existing tests passed.

[easingthemes]

Nice feature — backward-compatible defaults hold up (verified the default-config path is preserved) and the fixtures/tests are thorough. A few correctness issues surface once the new opt-in flags are used, plus one watch-mode regression that affects the default workflow. Details inline.