Web worker cache invalidation

tinkyholloway commented 2 years ago

Web workers are created by providing the path to the worker at run time:

let bridge = MyWorker::spawner()
    .spawn("/my_worker.js"));

This means that the site creating the worker needs to know the name of the worker. Indeed trunk deactivates the hashing of workers because to continue to use a hashed file name would require that dependent workers are built before any components that create them and then some how the hashed filenames are compiled into the spawn position.

The problem with turning off hashed file names in the workers though is that old versions can persist in caches.

One way to achieve the cache invalidation that seems doable without complicating the build process is that each time a build takes place a UUID is generated. This BUILD_UUID is passed in the environment to cargo build and can therefore be used when spawning like

let bridge = MyWorker::spawner()
    .spawn(format!("/my_worker-{}.js", env!("BUILD_UUID")));

when workers are built, wasm-bindgen outputs to the same -{BUILD_UUID} suffexed filename. The same BUILD_UUID is used for all workers built in the same build so that the build order of rust assets is not important.

It's not pretty, but it's the best I could come up with. Are there any other ideas on how to approach this?

thedodd commented 2 years ago

Thanks for opening the issue. This is ultimately one of the goals of the eventual Trunk library. It would be an optional library which app developers could pull in which would provide deeper compile-time integration with the Trunk CLI:

Trunk CLI would be updated to generate an asset manifest with hashes of asset sources and all;
Trunk would generate this asset manifest very early on in the build pipeline before it starts compiling assets;
This data would then be injected into the build env of any Rust assets while they are being compiled;
The Trunk lib would then be able to read this env info, extract matching hashes and expected final output names, and accurate update the Rust code at compile time with this info;

The original idea for this was related to being able to declare images to be included in your web app components via the Trunk library. Using this same scaffolding for web workers is a perfect fit though.

Thoughts?

thedodd commented 2 years ago

Another option is to spit out the pertinent parts of this asset manifest as JSON or something of that nature, and in-line it into the final HTML. That way components and such could literally just extract this data from some canonical location of the HTML <head>, and then use that info at application runtime. Thoughts?

This option would require far less work, and should work just as well. The Trunk runtime lib could encapsulate a canonical "API" for this pattern, how to extract and parse this data, and so on. We could call it TrunkDynamicAssets or the like.

futursolo commented 1 year ago

Another option would be to implement hashes on workers alongside #425.

If a shim script is created, the shim script can be configured like index.html with cache-control: no-cache where the actual worker bundle can have hashes and avoid being downloaded repeatedly.

extrawurst commented 10 months ago

any preference here on how to implement this?

github-actions[bot] commented 9 months ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

extrawurst commented 9 months ago

i believe this is still relevant. i more than once ran into the issue of my worker_bg.wasm being outdated because it cannot do cache-busting via hash in the name

github-actions[bot] commented 8 months ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

extrawurst commented 8 months ago

Still relevatnt

trunk-rs / trunk

Web worker cache invalidation #405