Build, bundle & ship your Rust WASM application to the web.

• Github repo
• Release notes 0.7.0
• Release notes 0.6.0
• We now have a brew package available. Just brew install trunk. Works on MacOS, Linux & Windows (WSL). Woot woot!

This release covers the 0.6.0 & the 0.7.0 releases of Trunk. We'll get to the nitty-gritty of these releases shortly, but I wanted to take a moment to talk about where Trunk is at now and where myself and others in the community would like to take Trunk in the future.

First of all, and most importantly, I believe we have finally found a perfect pattern for declaring asset pipelines in the source HTML (typically a project's index.html). The pattern which is now the standard as of the 0.7.0 release is as follows: <link data-trunk rel="{pipelineType}" data-other data-attrs data-here />. Let's break this down.

• Every asset pipeline, everything Trunk does in relation assets, is now controlled by normal HTML link tags with the special data-trunk attribute. This simple mechanism makes clear which links are intended for Trunk to process and which are not.
• Trunk links must have the rel attribute, a living standard HTML attribute which normally declares the relationship of the referenced resource to the HTML document. In our case, this represents the Trunk pipeline type. See the Trunk README #assets section for more details on supported assets and their attributes.
• Speaking of attributes, all pipeline types will require some number of attributes. Most require the standard href attribute to reference some target file. Others take non-standard attributes which are always prefixed with data-. E.G., the rel="rust" pipeline type is an optional pipeline type, if omitted Trunk will use the Cargo.toml in the source HTML's directory; however, if your cargo project exposes multiple binaries, you will need to specify which binary Trunk should use. This pipeline type supports the data-bin="bin-name" attribute for exactly that reason. Check out the aforementioned assets section in the README for more details.

Awesome! I'm very excited about how much this pipeline API has evolved. It is VERY extensible (what can't you specify via data-* attributes?), and my hope is that this pipeline API will ultimately become the 1.0 API for Trunk. However, Trunk is a young project, and still has a long way to go. Let's talk about the future.

Trunk's Future

There are lots of great features the Trunk community has been discussing, a few notable ones:

• support for automatic browser reloading via WebSockets or SSE. This is definitely par for the course as far as web bundlers are concerned.
• WASM HMR (hot module reloading). This is just an extension of the above, however there is a lot of awesome potential here. Building Rust WASM web applications is quite a lot of fun these days.
• inline CSS, JS and other applicable asset types. This will be an easy extension to the new pipelines API discussed above. For most of these asset types, it will be a simple data-inline attribute, and Trunk should be able to generate the necessary code to have the associated asset inlined.
• CSS components pattern. This is something which I personally think would be pretty cool. For those of you that remember EmberJS from back in the day, they had a nice feature where one could just place their CSS right next to their components, and they would be concatenated and served for you. Easy lift for Trunk, and folks might find it quite useful.
• A BIG LIFT: a Trunk library which will allow folks to declare assets directly in their Rust code right next to their WASM components. Already lots of discussion on this feature, still some planning and design work to do.

I've said a lot, so I'll say one last thing here: Trunk is an excellent project to get involved with! The new pipeline API has come along with an awesome refactor of the internal layout of the code. Adding new asset pipelines and pipeline extensions is easy and enjoyable! This community would be even better with you involved! Cheers mate! Let's do this!

the nitty-gritty

0.7.0

changed

• All assets which are to be processed by trunk must now be declared as HTML link elements as such: <link data-trunk rel="rust|sass|css|icon|copy-file|..." data-attr0 data-attr1/>. The links may appear anywhere in the HTML and Trunk will process them and replace them or delete them based on the associated pipeline's output. If the link element does not have the data-trunk attribute, it will not be processed.

fixed

• Fixed #50: the ability to copy a file or an entire dir into the dist dir is now supported with two different pipeline types: <link data-trunk rel="copy-file" href="target/file"/> and <link data-trunk rel="copy-dir" href="target/dir"/> respectively.

removed

• The manifest-path option has been removed from all Trunk subcommands. The path to the Cargo.toml is now specified in the source HTML as <link rel="rust" href="path/to/Cargo.toml"/>. The href="..." attribute may be omitted, in which case Trunk will look for a Cargo.toml within the same directory as the source HTML. If the href attribute points to a directory, Trunk will look for the Cargo.toml file in that directory.

0.6.0

added

• Closed #59: Support for writing the public URL (--public-url) to the HTML output.

fixed

• Closed #62: Improved handling of file paths declared in the source index.html to avoid issues on Windows.
• Closed #58: The output WASM file generated from the cargo build is now determined purely based on a JSON build plan provided from cargo itself. This will help to provide a more stable pattern for finding build artifacts. If you were running into issues where Trunk was not able to find the WASM file built from cargo due to hyphens or underscores in the name, that problem should now be a thing of the past.
• The default location of the dist dir has been slightly modified. The dist dir will now default to being generated in the parent dir of cargo's target dir. This helps to make behavior a bit more consistent when executing trunk for locations other than the CWD.
• Fixed an issue where paths declared in a Trunk.toml file were not being treated as relative to the file itself.