Restore manganis optimizations

[ealmloff]

This PR will restore the bulk of manganis with a slightly different serialization approach. It also restores all of the documentation that was removed in #2779. Instead of parsing the builder inside of the macro and serializing that into json, this PR serializes the builder directly. This should make it easier to add new asset types to manganis and make the macro significantly more flexible.

Previously the macro would only accept literals, now it will be able to accept any const type:

const ASSET: Asset = asset!("/assets/image.png");
const OPTIONS: ImageAssetOptions = ImageAssetOptions::new().with_format(ImageFormat::Avif);
const AVIF_ASSET: Asset = asset!("/assets/image.png", OPTIONS);

The path itself still needs to be a literal string so we can validate and hash the contents at compile time, but the rest of the settings are just const rust

closes #3229

[ealmloff]

I tried testing this on Windows 10 and I got this behavior:

• trying to use a folder asset and it errors with access denied
• assets are optimized and the optimized assets are placed in my top-level assets folder (nothing about assets in the target folder)
• the link returned by manganis for use in img src/document::Link is weird/doesn't work:

http://127.0.0.1:8080/assets///?\C:\Users\Darka\Documents\Projects\DioxusLabs\temp\web-manganis-test-3195\assets\main-e6ddccc1e64cc12d.css=

All of those issues should be fixed now (tested on windows 11). There was a path separator issue in manganis on windows

[jkelleyrtp]

Small tweaks:

• might be good to pull out the assets module from the CLI into its own crate
• some of the code we generate in the macro could be moved into a const function or two
• some docs in some places refernce the old mg!() or are incomplete, presumably since they're already incomplete.
• it would be nice if the serialized bytes were valid json but I get how the const_serialize can't do that in a general case.
• double check any issues with us not properly cleaning the build dirs - I want to make sure there's no weirdness with leftover html/assets/gradle files still showing up between builds leaving sticky state behind.

Overall much better!

[jkelleyrtp]

ImageAsset::options() might be more discoverable?

[ealmloff]

ImageAsset doesn't exist. We can't support metadata about assets like lqip or the sha without injecting it in the linker, so I didn't add it in this PR because of the time constraint

[jkelleyrtp]

do we want to be actually hashing assets at compile time? I'm a bit worried about long compile times - maybe there's a way we can inject metadata into the assets on the filesystem such that the hash gets included into the name during macro expansion?

[ealmloff]

Metadata isn't preserved in git, so we shouldn't use it for asset versioning. We want the hash to change only when the asset actually changes so the client can use the cached version if possible. When we were using the hash based on the metadata last modified time, it changed every time you pulled the git repo which causes a lot of issues in CI.

We could only hash the file in release mode if compile times are an issue. In debug mode, we disable caching anyway so it doesn't matter.

[ealmloff]

The hashing here should be really cheap, hashing the contents in the file in the macro could get expensive. I'm not sure how we can check if a macro is being expanded from a debug or release mode crate

[jkelleyrtp]

it really would not be terrible to cut out the asset system (Manifest, optimizer, etc) into its own crate again... and maybe with some feature flags so we can gate dev mode dx to not have to include all this.

[ealmloff]

Agreed. I would like to pull out asset optimization and resolution into a separate crate, but I don't want to block the release and it would take longer to make an more stable API. How about a follow up PR after more pressing issues like the base path are fixed? I have an issue ready once this is merged

[ealmloff]

it would be nice if the serialized bytes were valid json but I get how the const_serialize can't do that in a general case.

I think that is possible, but it would require a lot more logic to parse and format strings and numbers at compile time. I'm not sure how that would effect compile times, but it could be worth exploring in the future

I don't love having a bespoke serialization format. https://github.com/jamesmunns/postcard is a much simpler well defined serialization format that might be easier to target than json. I think it is pretty similar to what we are currently generating

[DogeDark]

All of those issues should be fixed now (tested on windows 11). There was a path separator issue in manganis on windows

I still have all the same issues on the latest commit except the folder asset now panics as todo during the CLI's asset stage

[ealmloff]

• assets are optimized and the optimized assets are placed in my top-level assets folder (nothing about assets in the target folder)
• the link returned by manganis for use in img src/document::Link is weird/doesn't work:

Can you share the code you used that causes those issues with the latest version? This code works as I would expect on windows:

use dioxus::prelude::*;

fn main() {
    launch(|| {
        let asset = asset!("/assets/img.png");
        rsx! {
            img {
                src: "{asset}"
            }
        }
    })
}

[DogeDark]

@ealmloff https://github.com/DogeDark/manganis-3195

[ealmloff]

@ealmloff https://github.com/DogeDark/manganis-3195

Thanks, that example is working now as well. I was testing windows on desktop where path separator in the CLI is the same as the target platform path separator. WASM has unix path separators so it was stripping the wrong path when cross building to web

[DogeDark]

Thanks, that example is working now as well.

I can confirm, it works!