Release of Trunk 0.19.0

The release of Trunk 0.19.0 has a focus on making life easier when creating Rust-based web applications. Find out what’s new in this blog post.

The general theme of this release was to improve the flexibility of Trunk, enabling more control over the build process and making it available for more environments.

Paths & prefixes

A repeated pattern of requests for Trunk was around public URL base, and how it can be controlled. There had been two constructs, one being the base URL at which the application was expected to be hosted later on. While the other was the base URL Trunk would serve the application from when using trunk serve. The latter one could only use a non-relative path, but also could not use a full URL. While the base URL (public URL) could basically be anything, including a relative path prefix.

Due to those conflicting requirements, there had been a few special treatments of the --public-url parameter, with some assumptions that worked for many, but not everyone.

While keeping the current default, Trunk 0.19.0 adds some more knobs that can be used to control both values individually. Read more about those here: Base URLs, public URLs, paths & reverse proxies.

Another use case was the requirement to be able to control the output path of assets inside the distribution folder. So far, all assets (generated or copied) went into the root of the distribution folder. Again, something that works for most, but not everyone.

In Trunk 0.19.0 it now is possible to use the data-target-path attribute on all asset elements. Allowing for a finer grained control of where resourced end up.

All those features can be used, for example, to move static resources into a sub-folder, and have them cased by a CDN, keeping the same base. Or it is possible to put a reverse proxy in front of trunk serve, allowing for more complex development setups.

Application initialization hooks

When a web application gets loaded, a JavaScript snippet in the HTML file will fetch the WebAssembly BLOB and then instantiate it. That works well, but has some downsides: for one, you don’t see any progress loading that initial BLOB. Second, when something fails, you only see that on the browser console. And last, once it’s loaded, don’t have access to the WebAssembly instance.

wasm_bindgen has most of the glue code to load the WebAssembly application. Trunk only adds a snippet inline, to load that snippet generated by wasm_bindgen. It’s now possible to add an initializer to this process, which gets called during the initialization process, allowing to get the current progress, the status, and the final WebAssembly module instance.

For a complete example, check out:


When making requests for downloading tools or towards configured reverse proxy targets, it is not possible to control the use of a proxy for such connections. This may be useful when you can to proxy towards internal systems, or need to deal with corporate network setups.

Part of the released binaries are also versions for Linux/MUSL now. Again, glibc works fine for most, but sometimes the glibc versions don’t align one you get linker errors. Requiring you to self-compile trunk. Especially in CIs this can be a time-consuming job. Using MUSL might just make your life easier.

By default, trunk will still use rustls for both client and server side TLS functionality. However, sometimes people prefer to use the system native TLS implementation. That’s now an option, by using an additional feature during build time.

Also, IPv6 is here, and trunk can now deal with it. It’s as simple as that. Can it be disabled? Sure!

Trunk version

Trunk is now aware of its own version. And it brings two features with that. One is an update check, which will check once a day on startup if there’s a new version. So you’ll never miss an update 😉

The second feature allows you to put a minimum required Trunk version into the Trunk.toml file. This can come in handy when you’re using some features that only exist with a certain trunk version. The version is a Rust SemVer range and can also include pre-release versions.

There’s only one caveat: This feature is only present starting with Trunk 0.19.0. So while you can set the minimum required trunk version to 0.19.0 when using new features, Trunk 0.18.x or before will not honor that setting and not raise an error. But it will be there for the next version.

Bug fixes & performance improvements

Of course, this feature also contains some bug fixes. Most notably, there had been some startup issues when the startup partially failed. The trunk process could just hang. There was a race condition in the build pipeline leading to numerous parallel builds. Intermediate files used a hashed name, which lead to a growing target directory. And a bunch more issues.

What’s next?

For you? Well, I would hope that you’ll give it a try and report any issues that might come up. Check out the easiest ways to get started.

For Trunk? That depends. There are a lot of ideas and things that can be improved. PRs welcome 😉.

If you’re interested, maybe join the Trunk Discord channel or create an issue/discussion on GitHub.

  • Paths & prefixes (see:
  • Application initializer hooks (see:
  • Trunk versions (see: and
  • Broader environment support (musl target, IPv6, proxies, …)