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

”Pack your things, we’re going on an adventure!” ~ Ferris

Trunk

.

Trunk is a WASM web application bundler for Rust. Trunk uses a simple, optional-config pattern for building & bundling WASM, JS snippets & other assets (images, css, scss) via a source HTML file.

📦 Dev server - Trunk ships with a built-in server for rapid development workflows, as well as support for HTTP & WebSocket proxies.

🏗 Change detection - Trunk watches your application for changes and triggers builds for you. Browser reloading, HMR, and other related features are in-progress.

Getting Started

Head on over to the Trunk website, everything you need is there. A few quick links:

  • Install
  • App Setup
  • Assets
  • Configuration
  • CLI Commands

Examples

Check out a few of the example web applications we maintain in-repo:

  • Yew + ybc: demo app built using Yew & ybc.
  • Seed: demo app built using Seed.
  • Vanilla: demo app built using plain old web-sys.

Contributing

Anyone and everyone is welcome to contribute! Please review the CONTRIBUTING.md document for more details. The best way to get started is to find an open issue, and then start hacking on implementing it. Letting other folks know that you are working on it, and sharing progress is a great approach. Open pull requests early and often, and please use Github's draft pull request feature.


License

trunk is licensed under the terms of the MIT License or the Apache License 2.0, at your choosing.

Issues

Collection of the latest Issues

CohenArthur

CohenArthur

0

Hi everyone, I might be going the wrong way about this but I am trying to have my web-app get launched with command line arguments. Specifically, I'm looking for a way to specify the API's URL to use, so that you could do something like this:

I can't for the life of me figure out how to get trunk to pass these arguments to the underlying web-app. I've looked at the various hooks and the trunk.toml example file, but nothing struck me. Am I missing something obvious?

It seems that it should be possible, considering that clap works with WASM or that the WASI specification allows it. Is that not the preferred way to go about it?

If it isn't implemented yet, I'd love to try and help wherever I can should you choose to add that :)

Thanks a lot for working on this project, it's been a blast to use and made Rust + WASM super easy to do even for a complete web noob like me.

huntc

huntc

0

We've stumbled across an issue that appears to be apparent only when running on Linux. We have a trunk.toml file containing a public_url declaration. On macOS and Windows, this is correctly substituted in our dist/index.html. On Linux, it isn't.

However, if --public-url is declared at the CLI e.g. trunk build --release --public-url=/something then all is well on Linux (and macOS from observation).

Our workaround is to use the command line argument. I did notice that the command line option is defaulted with a /. Perhaps the toml value should be the default?

jfkonecn

jfkonecn

0

I had the same issue as #394.

I had to directly modify the source code to get trunk to compile.

I'm new to rust, but I'm assuming the issue is that you're using newer language features which makes some people's compilers unhappy.

I was wondering if you would be okay with allowing those two lines of code to be modified so that more people do not experience this issue going forward.

I don't want people to not try trunk just because of something minor like this.

Not a big deal if you disagree, but I thought I'd ask just in case this was unintentional.

Keep up the good work!

inf0rm4tik3r

inf0rm4tik3r

1

Sometimes, a trunk serve just gets stuck at

INFO copying generated wasm-bindgen artifacts

Most of the time, issuing Ctrl+C to exit the process just does nothing.

Sometimes, closing the terminal where trunk was running and opening a new terminal resolves the issue, but sadly not every time. It then gets stuck at the same point, opening a browser window (if configured) but not showing the current state of the application.

I still have no idea why this happens.

tiye

tiye

1

when passed from CLI, the config of public_url is checked and ensure it starts with /: https://github.com/thedodd/trunk/blob/v0.15.0/src/config/models.rs#L30 https://github.com/thedodd/trunk/blob/v0.15.0/src/common.rs#L25-L29

however it's not ensured when passing from config file. It's inconsistent.

meanwhile in my case I need to use ./ to make sure it resolves files relative to current path. I suppose it should be valid.

what are the design decisions of Trunk?


update, also noticed the error actually came from the router, which does not allow ./ being used as a path. however the function above also causes confusing issue creating /./ at release build.

anatawa12

anatawa12

2

For macOS aarch64, I think trunk should download x64 version of wasm-bindgen instead of throwing error unsupported architecture because aarch64 mac can run x64 binaries with Rosetta.

GRASBOCK

GRASBOCK

0

I have a docker container from which I want to serve my yew website with trunk. I don't want to rebuild from source every time I run the container as it can be built once and then just served. Basically I want to cache the dist folder. While it serves fine without the source, it gives the error message

It would be nice to be able to turn off the error/build process just for serving. Though this is not a deal-breaker.

sagedemage

sagedemage

0

Hi this is Salmaan. I was installing trunk for my Raspberry Pi with cargo for my raspberry pi web server. I used zram on my system to compile it faster. Trunk failed to compile according to this error.

Error message: trunk compile issue

About my Hardware:

  • Computer: Raspberry Pi 3 Model B
  • Architecture: aarch64
  • RAM: 960 MB
  • CPU Cores: 4
  • Storage space: 256 GB

About my System:

  • OS: Raspberry Pi OS (Debian 11 bullseye)
  • Kernel Version: 5.15.32-v8

Rust Packages:

  • rustc version: 1.61.0
  • cargo version: 1.61.0
  • trunk version: 0.15.0
  • rustup version: 1.24.3
goodidea-kp

goodidea-kp

0

here is stack:

circleci local execute --job build-fromkos Fetching latest build environment... Docker image digest: sha256:99594af5fc8997d16fff35b757982b72e47c8ceebf833e99b05559c216545e65 ====>> Spin up environment Build-agent version () System information: Server Version: 20.10.16 Storage Driver: overlay2 Backing Filesystem: extfs Cgroup Driver: systemd Cgroup Version: 2 Kernel Version: 5.15.0-30-generic Operating System: Ubuntu 22.04 LTS OSType: linux Architecture: x86_64

Starting container rust:latest rust:latest: using image [email protected]:48d3b5baf199dc7c378e775c47b0c40aaf7d8b23eaf67e15b095bbdaaecd1f10 pull stats: Image was already available so the image was not pulled time to create container: 100ms Creating Docker containers in parallel Warning: No authentication provided, using CircleCI credentials for pulls from Docker Hub. Time to upload agent and config: 2.764724592s Time to start containers: 453.183342ms WARN: Missing API Key. ====>> Preparing environment variables Using build environment variables: BASH_ENV=/tmp/.bash_env-localbuild-1653180056 CI=true CIRCLECI=true CIRCLE_BRANCH= CIRCLE_BUILD_NUM= CIRCLE_JOB=build-fromkos CIRCLE_NODE_INDEX=0 CIRCLE_NODE_TOTAL=1 CIRCLE_REPOSITORY_URL= CIRCLE_SHA1= CIRCLE_SHELL_ENV=/tmp/.bash_env-localbuild-1653180056 CIRCLE_WORKING_DIRECTORY=~/project

The redacted variables listed above will be masked in run step output.====>> Checkout code Making checkout directory "/root/project" Copying files from "/tmp/_circleci_local_build_repo" to "/root/project" ====>> git clone https://github.com/thedodd/ybc.git #!/bin/bash -eo pipefail git clone https://github.com/thedodd/ybc.git Cloning into 'ybc'... remote: Enumerating objects: 372, done.
remote: Counting objects: 100% (167/167), done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 372 (delta 154), reused 135 (delta 135), pack-reused 205
Receiving objects: 100% (372/372), 125.78 KiB | 1.61 MiB/s, done. Resolving deltas: 100% (261/261), done. ====>> cp bugfix.patch ybc #!/bin/bash -eo pipefail cp bugfix.patch ybc ====>> git apply --ignore-space-change --ignore-whitespace bugfix.patch

#!/bin/bash -eo pipefail git apply --ignore-space-change --ignore-whitespace bugfix.patch

====>> wget -qO- https://github.com/thedodd/trunk/releases/download/v0.15.0/trunk-x86_64-unknown-linux-gnu.tar.gz | tar -xzf-

#!/bin/bash -eo pipefail wget -qO- https://github.com/thedodd/trunk/releases/download/v0.15.0/trunk-x86_64-unknown-linux-gnu.tar.gz | tar -xzf-

====>> ./trunk build --release

#!/bin/bash -eo pipefail ./trunk build --release

2022-05-22T00:41:03.683341Z INFO starting build 2022-05-22T00:41:03.683539Z INFO spawning asset pipelines 2022-05-22T00:41:48.880700Z INFO building fromkos 2022-05-22T00:41:48.880700Z INFO building fromkos 2022-05-22T00:41:48.881105Z INFO copying directory path="bs_pub" 2022-05-22T00:41:48.881901Z INFO finished copying directory path="bs_pub" Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache error: no bin target named worker error: no bin target named app 2022-05-22T00:41:49.787179Z ERROR error error from HTML pipeline

Caused by: 0: error from asset pipeline 1: error during cargo build execution 2: cargo call returned a bad status Error: error from HTML pipeline

Caused by: 0: error from asset pipeline 1: error during cargo build execution 2: cargo call returned a bad status Error: Exited with code exit status 1

Step failed Error: runner failed (exited with 101) Task failed Error: task failed

opensourcegeek

opensourcegeek

0

Just wondered if you have any suggestions to work around an issue I'm facing. When I run trunk serve, I see the following error message. I had a quick peek and it looks like it's an issue with rustls that reqwest depends on. I'm not sure if I could override the feature flags for reqwest or rustls directly as a consumer (looks like there's some 'dangerous' setting in rustls - but haven't looked into it fully). Is there another way I could manually download/copy these external deps so that trunk would just use that instead of trying to override reqwest flags and stuff. Thanks

mousetail

mousetail

3

I have a project containing multiple cargo workspaces, multiple servers and clients. I want to build only the client part with trunk. Right now the trunk process fails since it tries to build the servers for the wasm32-unknown-unknown target which fails since some dependencies don't support it.

I with there was a way to specify a single project in a workspace to build and just leave the others alone. Right now trunk seems to be trying to build anything no matter where the working directory is. Maybe a option on the config file?

casey

casey

0

Since watch is for me broken (I think it's#232) I'm using cargo watch --shell 'trunk build' to rebuild on save.

This worked, but once I added a copy-dir directive to index.html, trunk build started triggering my watch.

My copy-dir directive looks like this:

When adding --debug to the cargo watch invocation, it displays this:

So it looks like it's touching files in static.

Is trunk build touching files in copy-dir?

inf0rm4tik3r

inf0rm4tik3r

1

Running wasm-opt (from https://github.com/WebAssembly/binaryen) with option "-O2" on a generated wasm file build with the --release flag, shrinks the size of it quite significantly. In my case from ~2.6mb to ~1.9mb.

Would it be possible to, optionally, regarding the time overhead induced, include the execution of the wasm-opt tool in the build command, so that smaller and possibly more performant binaries can be generated by default?

Having a "as small as possible" wasm file should be desired in the web-landscape.

jmc-figueira

jmc-figueira

4

Similarly to #260, I'm facing an issue with running trunk in a Nix derivation:

The error resulting from this derivation is related to the fact that, during evaluation, Nix prevents creating directories outside the derivation output and trunk requires creating the cache directory, as such:

Now, I don't expect the maintainers of this project to support this very niche use case; however, I would just like some guidance on the cache directory's exact function (as it doesn't seem to be documented, hence I assume it to have some internal function which is opaque to the end user) and if it is possible to change its location at runtime in any way, as a workaround for this issue.

flosse

flosse

0

It would be cool if Trunk generates a standard HTML file when none is specified. Especially for examples this would be cool. Inside the seed repo there are about 50 examples we want to run with trunk and it would be great if we didnt have to have all the index.html` files lying around.

flosse

flosse

3

@thedodd How are you? I can imagine you're pretty busy. I just noticed that there are 30 open PRs and 102 Issues that haven't gotten this much attention in a while. Do you need any more maintainers to help you out, perhaps?

greenfierydragon

greenfierydragon

0

Trunk can build scss and sass files with <link rel="scss"... however it cannot preload them.

When I wrote:

Trunk errored out:

I really like trunk and I think this feature would make it a lot nice for larger projects which have a non critical sass aswell as inlined critical sass!

voidpumpkin

voidpumpkin

0

Given i have ran my website using trunk serve. When i edit my code to have a compiler error Then my cli shows the error but my website is still up as if everything is fine

I would expect trunk to either display "You have errors in you cli" or just plain old not serve that website when its incorrect.

I keep i working with my website after quick changes only to after 5 seconds find out im testing out outdated cashed version.

iwollmann

iwollmann

0

I was wondering if there is a way to have a conditional asset link, because I'm facing this issue working with the tailwindcss and this was the only way that I found to have a productive development process. https://stackoverflow.com/a/71464774/3826927

So I had to add an instruction for in the build process people remember to remove the script tag and uncomment the link tag.

danielnehrig

danielnehrig

1

Trunk does not detect file changes with neovim. Upon saving the file in neovim on version (0.6.1 and 0.7 nightly both using the --clean flag) no changes are detected by trunk

on the other hand with vim changes are detected there is probably a difference on how files are written to disc in both

though trunk should detect any change that happens to a file.

Reproduce:

  1. Install Trunk: cargo install trunk
  2. Install neovim (brew install neovim, ...)
  3. create a trunk project
  4. open nvim and a file :e ./src/main.rs
  5. save the file :w

Expected:

Trunk sees any kind of file change.

Infos:

noc7c9

noc7c9

0

Say I have a test API that echos back the URI path that was called.

Note: API is running on 3000

When setting up Trunk to proxy to this endpoint it proxies to /api/ when when the original path was /api.

Not the biggest deal by itself but my actual API server is set to redirect /api/ to /api which causes proxying to fail.

PS: thanks for the amazing project, it's honestly a lifesaver. Makes working with WASM an absolute joy tbh.

Versions

Find the latest versions by id

v0.15.0 - May 02, 2022

Hello everyone! I'm happy to announce the release of Trunk 0.15.0. After a long time of silence and partial inactivity, we're back on track with this fresh release.

We now have improved support for Web Workers, and the long requested feature, to disable the hashes in output files, has been added. Of course, there are tons of other changes and fixes as well.

added

  • Added the --address option for trunk serve.
  • Open autoreload websocket using wss when assets are served over a secure connection.
  • Added the data-type attribute to Rust assets. Can be set to either main (previous behaviour and default) or worker, which builds the asset and includes it as a web worker.
  • Added the --proxy-insecure option for trunk serve.
  • Added the insecure option to the proxy section in Trunk.toml.
  • It is now possible to disable the hashes in output file names with the new --filehash flag (for example cargo build --filehash false). Alternatively the build.filehash setting in Trunk.toml or the env var CARGO_BUILD_FILEHASH can be used.
  • Flags for enabling reference types & weak references in wasm-bindgen.
  • Added the data-typescript attribute to Rust assets. When present, wasm-bindgen will emit TS files for the WASM module.

changed

  • Remove the temporary output of the SASS compiler from the output directory of Trunk.
  • The trunk serve command now listens on 127.0.0.1 (localhost) instead of 0.0.0.0, fixing security issues when on a public Wi-Fi or otherwise accessible network connection. The address can still be changed with the Trunk.toml or --address cli argument.
  • Print the serving address with a protocol to make it to be recognized as an URL in some terminals #292
  • Bumped up the default version for the dart-sass, wasm-bindgen and wasm-opt tools to their latest available version.
  • For wasm-opt and dart-sass, use the system-installed version if no explicit version is set. Previously Trunk would check for a specific default version which was likely to be an older version.
  • All arguments are now logged in verbose mode, whenever an external binary is executed. Use trunk -v build ... (or some other sub-command) to try it out.
  • Replace the custom logic for serving the static assets, with some types from the tower-http crate. This reduces the amount of custom code needed to serve files.

fixed

  • Fixing double-builds caused by downgrading from notify v5 back to v4, which contains debounce logic for filesystem events.
  • Verify the target architecture when downloading tools in addition to the OS and fail if the architecture doesn't match, instead of downloading and try to run on mismatching architectures.
  • Force HTTP/1 on proxy client, which fixes #280.
  • Updated all dependencies to their latest versions, fixing several potential security issues.

v0.14.0 - Sep 20, 2021

added

  • Trunk now includes a hooks system. This improves many use cases where another build tool is needed alongside trunk, by allowing trunk to be configured to call them at various stages during the build pipeline. It is configured under [[hooks]] in Trunk.toml. More information can be found in the Assets section of the docs.
  • Added trunk serve autoreload websocket trigger which reloads the page when a change is detected. The --no-autoreload flag disables this feature.
  • Added the optional pattern_script field to the Trunk.toml for overloading the template of initialization script.
  • Added the optional pattern_preload field to the Trunk.toml for overloading the template of WASM preloading.
  • Added the optional pattern_params field to the Trunk.toml for extending pattern_script and pattern_preload with additional values, including external files. Overloading these parameters allow users to use trunk with other frameworks like this.

changed

  • Download and use the official dart-sass binary for SASS/SCSS to CSS compilation. This allows to always support the latest features and will allow to make Trunk available for futher platforms in the future as this removes the dependency on sass-rs.
  • Proxied websockets now shut down immediately upon completion of streaming data in either direction, instead of waiting for completion of both directions.

v0.13.1 - Aug 06, 2021

  • Fixed #219: Preserve websocket message types when sending to the backend.

v0.13.0 - Aug 06, 2021

  • Trunk has been fully cut over to Tokio 1.x.
  • As part of the Tokio cut over, the Trunk network stack is now fully based on Axum.
  • All download utilities have been made fully async. This will likely help us in the future as we continue to leverage this functionality more and more.
  • Added a new CLI option trunk clean -t/--tools which will optionally clean/remove any cached tools used by Trunk, such as wasm-bindgen & wasm-opt. This may be useful if there are ever issues with old tools which need to be removed.
  • Fixed #198 which was a long-standing issue with the static file server. In essence, Trunk will now check the accept header of any GET request matching the static file server, and if the requested asset does not exist and the accept header allows either */* or text/html, then return the index.html.
    • This is expected functionality for SPAs which are using client side routing.
    • This reduces the friction which has often been observed with Trunk where a user is expecting a 404 to be served when requesting a static image, CSS, or some other asset which does not exist. With this update, 404s will now be returned as expected, and the index.html should only be returned for applicable cases.
  • Added a new proxy example which demonstrates all functionality of the Trunk proxy system.
  • Fixed #209 where the default Rust App pipeline was causing wasm-opt to be used even for debug builds when the Rust App HTML link was being omitted.
  • Closed #168: RSS feed for blog.
  • Isolated code used for version checking & formatting of version output for downloadable applications (wasm-bindgen & wasm-opt). Added unit tests to cover this logic.
  • Fixed #197 & #175 where disabling wasm-opt for debug builds while keeping it enabled for release builds was not possible without some hacking. Now, wasm-opt will only be used for release builds and only when enabled. This semantically matches cargo's behavior with optimizations in release mode.

v0.12.1 - Jul 28, 2021

0.12.1

fixed

  • When wasm-opt level is not set explicitly, do not invoke it at all for debug builds, and for release builds invoke with default optimization level.

v0.12.0 - Jul 28, 2021

0.12.0

added

  • Closed #139: Download and manage external applications (namely wasm-bindgen and wasm-opt) automatically. If available in the right version, system installed binaries are used but if absent the right version is downloaded and installed. This allows to use trunk without the extra steps of downloading the needed binaries manually.
  • Added an example application for using Trunk with a vanilla (no frameworks) Rust application.

changed

  • wasm-opt is now enabled by default (with default optimization level) as the binary is automatically downloaded and installed by trunk. It can still be disabled by setting data-wasm-opt to 0.

Big shoutout to @dnaka91 for his excellent work on this feature! Top-notch, sir. Thank you.

v0.11.0 - Apr 14, 2021

added

  • #158: Support for inlining SASS/SCSS after compilation using the new data-inline attribute.
  • #145: Preloading of the WASM and JS files are now added to the <head> element. This ensures that the code starts downloading as soon as possible, and can make your app start up a few seconds earlier on a slow network.
  • #135: Allow users to specify data-keep-debug & data-no-mangle options on Rust build pipelines, which influence their corresponding wasm-bindgen CLI options.
  • #60: Added data-cargo-features attribute for rust asset type.

fixed

  • #148: Any changes detected under a .git path are now being ignored by default.
  • #163: Allow using copy-file assets on files which do not have a file extension.

v0.10.0 - Mar 12, 2021

changed

  • Completely removed indicatif from the code base, and now we are using the tracing crate. This has greatly simplified the code base. Only downside ... no more progress spinner. Per a fair bit of demand however, cargo output and output from other subprocess calls are now piped directly to stdout/stderr for better visibility into what is happening behind the scenes.
  • This also addresses a few issues/inconsistencies around colored output on Windows.

v0.9.2 - Mar 09, 2021

fixed

  • Fixed a bug where build pipeline errors were being hidden/masked on subsequent builds.

v0.9.1 - Mar 08, 2021

fixed

  • Fixed a bug releated to the watch system, which would cause build loops if there was an error on the initial build.

v0.9.0 - Mar 06, 2021

added

Added support for proxying WebSockets. This was a long-standing feature request. Due to changes upstream in the async-std/tide ecosystem, we are now able to properly support this. This will also unlock some nice features such as HMR via WebSockets, and other such niceties.

  • Added the --proxy-ws CLI option for enabling WebSocket proxying on a CLI defined proxy.
  • Added the ws = true field to the Trunk.toml [[proxy]] sections which will enable WebSocket proxying for proxies defined in the Trunk.toml.
  • WASM files are now automatically optimized with wasm-opt to reduce the binary size. The optimization level can be set with the new data-wasm-opt argument of the rust asset link andwasm-opt binary is now required to be globally installed on the system when being used. E.G., <link data-trunk rel="rust" [...] data-wasm-opt="4"/>.

fixed

  • Closed #81: this is no longer needed as we now have support for WebSockets. HTTP2 is still outstanding, but that will not be a blocker for use from the web.
  • Closed #95: fixed via a few small changes to precendce in routing.
  • Closed #53: we've now implemented support for proxying WebSockets.

v0.8.3 - Mar 03, 2021

fixed

  • Fixed #133 where watch was infinitely looping on Windows because the canonicalization path didn't match the un-canonicalized ignore list. Windows likes to use a ? prefix on paths sometimes ... ???

v0.8.2 - Feb 16, 2021

fixed

  • Round two of fixing #124 where path canonicalization was being performed on a path which did not yet exist, and as it turns out was already in canonical form.

v0.8.1 - Feb 04, 2021

fixed

  • Fixed #124 where path canonicalization was being performed on a path which did not yet exist, and as it turns out was already in canonical form.

v0.8.0 - Feb 02, 2021

added

  • Closed #93: The watch and serve subcommands can now watch specific folder(s) or file(s) through the new --watch <path>... option. Thanks to @malobre for all of the work on this one.
  • Inline the content of files directly into index.html with the new inline asset. There are three content types that can be inlined: html, css, and js. The type can be specified with the type attribute or is inferred by the file extension. Thanks to @DzenanJupic for all of the work on this one.

fixed

  • Closed #49: old artifacts in the dist dir are now being cleaned-up as new builds successfully complete. Thanks @philip-peterson & @hamza1311 for their work on this one.
  • Fixed infinite rebuild loop on Windows started by watch command by path canonicalizing in the ignored paths resolver.

v0.7.4 - Oct 23, 2020

fixed

  • Fixed a regression in Trunk CLI help output, where incorrect help info was being displayed.

v0.7.3 - Oct 16, 2020

fixed

  • Closed #82: Remove the hardcoded Unix (/) path separator from the code and convert Windows NT UNC path to its simplified alternative before passing to cargo metadata command to prevent issues with Rust package collisions and writing index.html file.
  • Updated the WatchSystem to use {:?} debug formatting for errors to ensure that full error chains are reported. This impacts the watch & serve subcommands. The build command was already behaving as needed.

v0.7.2 - Oct 11, 2020

0.7.2

fixed

  • Closed #78: Ensure all asset pipelines are properly rooted to the configured public-url, which defaults to /.

v0.7.1 - Oct 10, 2020

0.7.1

fixed

v0.7.0 - Oct 08, 2020

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 - Oct 01, 2020

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.

v0.5.1 - Sep 23, 2020

  • 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.

v0.5.0 - Sep 23, 2020

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:

v0.4.0 - Sep 16, 2020

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.

0.3.1 - Aug 30, 2020

0.3.1

fixed

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

0.3.0 - Aug 30, 2020

0.3.0

added

  • Handle multi-project & workspace contexts.

0.2.0 - Aug 30, 2020

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.

v0.1.3 - Aug 27, 2020

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.

v0.1.2 - Aug 27, 2020

0.1.2

changed

  • Swap our grass for sass-rs.
  • Compress SASS/SCSS output when building in --release mode.

v0.1.0 - Aug 26, 2020

I am happy to announce the very first release of Trunk. Trunk is a CLI tool, written in Rust, which provides a simple, zero-config pattern for building Rust WebAssembly applications, bundling application assets (sass, css, images &c) and shipping it all to the web.

Trunk is designed for creating progressive, single-page web applications, written in Rust, compiled to WebAssembly, without any JS (though today JS is still needed for loading WASM modules). Trunk follows a simple paradigm: declare an index.html file describing the single page of your application, then Trunk will parallelize bundling assets declared in your HTML, will build your WASM app, hash resources for cache control ... all without any extra config files.

Getting Started

Getting up and running with Trunk couldn't be easier. Head on over to the Getting Started section of the README for more details.

Features

Trunk ships with a built-in sass/scss compiler, a web server for serving your content during development, responds to file system changes while you work to trigger builds, and has other features already available and many others in the works. Check out the readme for more details.

Future

Trunk was born out of necessity. Personally, I have been SO eager to be able to build web applications entirely in Rust. The stability of Rust language overall, the ability to refactor and move quickly, the ability to scale out a code base with confidence ... a night and day difference from building non-trivial JS/TS web applications. I realized many times over that last few years that this is exactly the sort of tool we needed in the Rust WASM community to really help with ease and speed of development, and the lack of a tool like this was a major roadblock for me multiple times. I sincerely hope that Trunk will help us all forward on this path.

After some discussion with folks in the community, I would love to be able to leverage wasm-pack in the Trunk build pipeline. At a minimum for managing wasm-bindgen versions/installation, but perhaps to a further extent as well (see #5).

There are lots of other features in the works. SSE from the server to trigger reloads. WASM HMR (faster than reloads, but probably a bigger effort). Support for more asset types, minification, etc, etc. Lots to do.

Though this project is just a baby, it is usable right now, and I am currently using it for a personal project. I hope you find the time to use it, and if you do, please take the time to report your findings. What worked for you? What are some things which you still need? Any and all feedback is appreciated. Let's do this!

”Pack your things, we’re going on an adventure!” ~ Ferris

Information - Updated Jun 22, 2022

Stars: 1.7K
Forks: 119
Issues: 130

Repositories & Extras

maomi: A rust wasm framework for building pages with components

maomi is a MVVM-like framework for web development

maomi: A rust wasm framework for building pages with components

Rust / Wasm client web app framework

Pull requests which improve test coverage are also very welcome

Rust / Wasm client web app framework

A Rust/WASM Library to interact with Bitcoin SV

npm i bsv-wasm-bundler --save

A Rust/WASM Library to interact with Bitcoin SV

WASM / Rust / D3 example

Fetch data with Rust + WASM and show it with JS + D3

WASM / Rust / D3 example

@texhno-rust-wasm-game-of-life

A template for kick starting a Rust and WebAssembly project using Tutorial

@texhno-rust-wasm-game-of-life

rust wasm worker hello world

Built using the template at which

rust wasm worker hello world

👷‍♀️🦀🕸️ rustwasm-worker-template

A template for kick starting a Cloudflare worker project using

👷‍♀️🦀🕸️ rustwasm-worker-template

Rust WASM Web Worker Examples

This repository contains four different examples of using web workers in conjunction with WASM in

Rust WASM Web Worker Examples

NES Emulator in Rust-WASM

Requires Rust with cargo, nodejs, and wasm-pack

NES Emulator in Rust-WASM
Facebook Instagram Twitter GitHub Dribbble
Privacy