Bundling assets from dependencies

[Azriel Hoh]

Heya, is it possible to bundle assets from dependencies?

e.g. web_app depends on web_components, and web_components defines its own assets.

My use case is shipping stylesheets in a components library crate, so that consumers who are building their own application don't have to make a copy of the stylesheet and maintain it.

[Jens Reimann]

No that I am aware of. But yes, that would be a nice addition.

[Evan Almloff]

This is an issue we were facing with dioxus. We are working on developing a library called Manganis that supports collecting and optimizing assets across dependancies. We are using it in the dioxus-cli, but it is built to work with any CLI. It could be used for cross dependency assets in trunk in the future

We implement a similar approach to what is described in #9

[Jens Reimann]

We implement a similar approach to what is described in #9

I think that describes a bunch of ideas :) … What exactly do you propose?

[Evan Almloff]

I think that describes a bunch of ideas :) … What exactly do you propose?

It implements something similar to option 0 in the original comment. You can link to a local asset with a macro which expands to the server URL (with a configurable base path).

// RUSTACEAN_URL is a url in the form `/base_path/asset_name_then_asset_hash`
const RUSTACEAN_URL: &str = manganis::mg!(file("https://rustacean.net/assets/rustacean-flat-happy.png"));

You can also use a builder syntax (with autocomplete) to modify the asset at compile time:

// ImageAsset implements Display to get the URL with additional information like a low quality image preview if that feature is enabled
pub const AVIF_ASSET: manganis::ImageAsset = manganis::mg!(image("./rustacean-flat-gesture.png")
    .size(52, 52)
    .format(ImageType::Avif));

Any CLIs that support Manganis (currently just the dioxus-cli) can use the manganis-cli-support library to collect, automatically optimize and copy those assets before the application is served.

[Jens Reimann]

so that would be part of the frontend code and compile when trunk would call cargo build, right? I assume that will create a tree of assets at some location, which then would need to be scooped up the bundler, e.g. trunk?

If that's the case, then I guess using copy-dir, would already work today: https://trunkrs.dev/assets/#copy-dir

I agree that it would be cool to auto-detect the use of manganis. Just trying to understand what would be required to do that.

[Evan Almloff]

so that would be part of the frontend code and compile when trunk would call cargo build, right?

Yes, manganis could be in the main package you are building or in any dependency that needs assets like a component library

I assume that will create a tree of assets at some location, which then would need to be scooped up the bundler, e.g. trunk?

The macro will just create a link to an asset. It doesn't copy or optimize the assets directly because macros are built in debug mode (by default) and a library doesn't know the location of the binary it is being used for

If that's the case, then I guess using copy-dir, would already work today: https://trunkrs.dev/assets/#copy-dir

I agree that it would be cool to auto-detect the use of manganis. Just trying to understand what would be required to do that.

Any CLI that supports manganis needs to:

1. save a config
2. Hold a guard when you build the project. This guard sets some environment variables that the macro reads
3. Load the asset manifest and copy the assets to the final location

Note that manganis is still in alpha and some of these APIs will change in the future (also open to any suggestions). I just found this issue and thought it might be worth reaching out to see if manganis would be useful for trunk.

[Jens Reimann]

I think it would be worth exploring this idea. I also think there could be multiple levels of integration. Maybe it makes sense forking off an issue working towards this. Just to be clear, I am happy to help, but I won't have time to do all the work.

[Jens Reimann]

Created a new issue: #759