v0.7.1 | Bug Fixes

0.7.1

fixed

• Closed [#76]((#76): Ensure canonical paths are used for pertinent paths in the runtime config to ensure watch config is able to properly ignore the dist dir and such.

v0.7.0 | Stable Pipeline API | Future Goals

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

We'll get to the nitty-gritty of this release 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!

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.

v0.6.0

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.

Fix a regression in server index.html fallback

• Closes #55: Fixed a regression in the server where the middleware was declared after the handler, and was thus not working as needed. Putting the middleware first fixes the issue.

Proxy System

Trunk now ships with a built-in proxy which can be enabled when running trunk serve. There are two ways to configure the proxy, each discussed below. All Trunk proxies will transparently pass along the request body, headers, and query parameters to the proxy backend.

proxy cli flags

The trunk serve command accepts two proxy related flags.

--proxy-backend specifies the URL of the backend server to which requests should be proxied. The URI segment of the given URL will be used as the path on the Trunk server to handle proxy requests. E.G., trunk serve --proxy-backend=http://localhost:9000/api/ will proxy any requests received on the path /api/ to the server listening at http://localhost:9000/api/. Further path segments or query parameters will be seamlessly passed along.

--proxy-rewrite specifies an alternative URI on which the Trunk server is to listen for proxy requests. Any requests received on the given URI will be rewritten to match the URI of the proxy backend, effectively stripping the rewrite prefix. E.G., trunk serve --proxy-backend=http://localhost:9000/ --proxy-rewrite=/api/ will proxy any requests received on /api/ over to http://localhost:9000/ with the /api/ prefix stripped from the request, while everything following the /api/ prefix will be left unchanged.

config file

The Trunk.toml config file accepts multiple [[proxy]] sections, which allows for multiple proxies to be configured. Each section requires at least the backend field, and optionally accepts the rewrite field, both corresponding to the --proxy-* CLI flags discussed above.

As it is with other Trunk config, a proxy declared via CLI will take final precedence and will cause any config file proxies to be ignored, even if there are multiple proxies declared in the config file.

The following is a snippet from the Trunk.toml file in this repo:

[[proxy]]
rewrite = "/api/v1/"
backend = "http://localhost:9000/"

Layered config (Trunk.toml), JS snippets & release binaries

added

• In addition to CLI arguments and options, Trunk now supports layered configuration via Trunk.toml & environment variables.
• Added an example Trunk.toml to the root of the repository showing all possible config values along with their defaults.

changed

• README has been updated with details on how the config system works.
• Removed a fair amount of code duplication as part of the configuration changes.
• Added full release automation with optimized release binaries for Linux, MacOS & Windows (all x64). Brew packages for MacOS and Linux, and a Chocolatey package for Windows coming soon.

fixed

• Closed #37: Trunk now exits with a non-zero code when an error takes place during execution.
• Closed #40: Trunk is now copying JS snippets from wasm-bindgen into the dist dir as part of the standard build/watch/serve commands.

Fix a regression in resolving WASM artifacts

0.3.1

fixed

• Fixed a regression in resolving cargo build's output WASM.

Suppport for multi-project & workspace contexts

0.3.0

added

• Handle multi-project & workspace contexts.

CLI progress spinner, --open to control browser opening, and other QOL improvements

0.2.0

changed

• All CLI output has been improved using console & indicatif. Builds, asset pipelines, and the like are using a progress spinner along with messages. All in all this provides a much more clean CLI output experience.
• Using console::Emoji to ensure that emojis are only sent to stdout/stderr when supported.
• All builds performed by trunk now emit warnings when a link is found in the HTML which is an invalid FS path. This does not effect hyperlinks of course.
• trunk serve now takes the --open option to control whether or not a browser tab will be opened. Thanks @MartinKavik for the report.
• The trunk serve listener info has been slightly updated. It continues to function as in previous releases. Thanks @MartinKavik for the report.

Process crate names correctly & default to `index.html`

0.1.3

fixed

• Closed #15: ensure cargo package name is processed as cargo itself processes package names (s/-/_/).
• Closed #16: default to index.html as the default target for all CLI commands which expect a target. This matches the expectation of Seed & Yew.

Thanks @MartinKavik for reporting these items.