cu-build.config.js

"imports": {
  "resources": [ 
    /* all unitframe related resources from the cu-components module */
    { resource: "cu-components/unitframe/images", dest: "images/unitframe" },
    { resource: "cu-components/unitframe/styles", dest: "styles" },
    /* just the portrait resources required */
    { resource: "cu-components/unitframe/portrait/images", dest: "images/unitframe/portrait" }
  ]
}

cu-components-package.json

"resources": {
  "$base": "lib/classes",
  "unitframe": {
    "images": [ "lib/classes/unitframe/images/*.png" ],
    "styles": [ "lib/classes/unitframe.css" ],
    "portrait": {
      "images": [ "lib/classes/unitframe/images/portrait/*.png" ],
      "styles": [ "lib/classes/unitframe/portrait.css"]
    },
    "$refs": [ "shared "]
  }
}

could nest like this then

{
  "resource": { 
    "unitframe": { 
      "images": [ "lib/classes/unitframe/images/*.png" ],
      "styles": [ "lib/classes/unitframe.css" ],
      "sub-component": {
          "some-styles": [ "lib/classes/unitframe1.css" ],
          "some-styles2": [ "lib/classes/unitframe2.css" ],
       }, 
      "include": [ "shared" ] 
    }, 
    "shared": { 
      "images": "...", 
      "styles": ["...", "..."]
    }
  }
}

should we name "include" to "_include" to minimize naming clashes?

they essentially a json tree, so unitframe/styles would map to unitframe.styles or unitframes/sub-component/some-styles would map to unitframe.sub-component.some-styles

If a consumer was to request unitframe/sub-component/some-styles how would the include be treated on top level unitframes? would it include everything along the way? or would dependencies be managed from the bottom up?

I think that there should only be one endpoint and no nesting within an endpoint:

i.e. unitframe is an endpoint providing assets, this should not have sub-components.

It should either provide sub components or asset paths, this would make things easier.. plus you could still import unitframe and it would grab all child components

Be careful about doing this as part of the build. The most important thing about resources is run-time de-duping. If a 2MB texture is used by 20 UI components, you've just grown the memory footprint by 40MB and potentially caused more driver state switches etc. As an example of how this can be blown out of proportion, refer to the classic AdBlock problem where a simple CSS file was exploding browser tab usage by 100MB a tab.

Re-using the same physical file at runtime is highly likely to be the king is this case. The build process should therefore figure out how to access shared resources in a uniform way and provide an e.g. json file with the path (possibly with placeholders: {baseUI}/foo/bar.png) so that resources can be shared.

Even if the engine can't currently de-dup across windows/processes, we should ensure that we don't tie the hands of CSE if they ever find resource sharing to be a performance problem.

Introduced a dest: option in the build config so that the build config can describe where particular resources should be placed.

For the stock UI 2.0, all images should probably be in images/* rather than character/images/*

Lets look at an example of a third party Target UI that want's to re-use the UnitFrame class of the cu-components library which defines a bunch of image resources that the stock UI uses.

Perhaps I am making only a slight change, or I am just adding some extra information, so I want to completely re-use the existing artwork and styles. I have a few choices.

1. In my html, I reference the stock UIs css. I have my own CSS to tweak / add to those stock styles

2. I have a custom (copy) of the stock CSS that I modify and point the image references at the stock images

3. copy the css and images resources into my output and reference those.

4. sounds good

5. maybe you want to resize some stuff, but really option 1 would be better

6. humm... you could but.

7. In this case, I would simply not copy the resources provided by the library but simply reference them.

8. Same for this case, because I would copy the CSS into my project and reference the stock images.

9. Why would you choose this option. For a mod it doesn't make sense.

I don't think this resource copying is necessary or desirable for a custom UI mod. It is being implemented to support stock UI development.

Elaborating on 3. If I was creating a mod that was using custom artwork, I would be providing my own or edited artwork and not copying those resources from the library.

Lets look at an example of a stock Target UI that wants to use the UnitFrame class of the cu-components library which defines a bunch of images resources that the stock UI uses.

In this case, the build will want to copy the resources into the build output. I accept that these should be in a shared location, so that multiple UIs using the same resources, the Target UI is a good example, as it shares resources with the friendly target UI and character UI.

So we need to be able to tell the build config to output these resources to a shared location rather than bundle them with each specific UI.

So, making an assumption that, the build output of cu-ui-v2 will be ./dist/... then building the three unit frame UIs should result in something like this:-

dist/images/unitframe/....png // frame art images
dist/images/unitframe/portrait/....jpg // portrait images (used by character UI only)
dist/styles/unitframe.css
dist/character/index.html
dist/character/main.js
dist/character.ui
dist/enemytarget/index.html
dist/enemytarget/main.js
dist/enemytarget.ui
dist/friendlytarget/index.html
dist/friendlytarget/main.js
dist/friendlytarget.ui

Yes, there is some duplication of copying of resources, as each of the character/enemy/friendly target UIs is built, but they all output to the same location, so the only duplication is in build not in the result.

But wait, there's more...

Sounds like what @csejb has in mind is that we won't need a separate copy resources stage for stock UIs because all the libraries resources will be included in a cu-components folder and the resources will be referenced directly from there.

"resources": {
  "$base": "lib/classes",
  "$sym": {
    "$lib": "../../../client/assets/webui/lib",
    "$cuui": "../../../client/assets/webui/cu-ui"
  },
  "unitframe": {
    "images": [ "lib/classes/unitframe/images/*.png", "$cuui/classes/unitframe/images/border.png" ],
    "styles": [ "lib/classes/unitframe.css" ],
    "portrait": {
      "images": [ "lib/classes/unitframe/images/portrait/*.png" ],
      "styles": [ "lib/classes/unitframe/portrait.css"]
    },
    "$refs": [ "shared "]
  }
}

I think after the chat with csejb we just had, I think this whole gist is obsolete!!

Stock UIs won't need to copy resources, they will simply reference them from lib//...

Custom UIs can either reference the stock resources lib//... in the same way or provide their own.