An implementation of the LinkedIn fork of DustJS written in rust.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Tom Alexander 5df2d19212
Updating README.
4 days ago
js Add a test case for casting booleans to numbers. 2 weeks ago
src Add an is_castable() function to stop casting to number for booleans in the @size helper. 2 weeks ago
.gitignore Update gitignore for compliance tests 2 months ago
Cargo.toml Add support for supplying multiple templates to the dustjs shim to support testing partials. 2 months ago
Dockerfile Integrate the dustjs official helpers into the test framework. 1 month ago
LICENSE Initial commit 2 months ago Updating README. 4 days ago


An implementation of the LinkedIn fork of DustJS written in rust.

WARNING: Early-stage project

While I’ve added a lot of tests proving a byte-for-byte compatibility with the official LinkedIn DustJS implementation, this project has not (afaik) been used in any sort of large production environment. If you find any incompatibilities between this implementation and the LinkedIn DustJS implementation, please let me know (or even better: commit a test under js/test_cases!).

Differences between duster and LinkedIn DustJS

Context Helpers

LinkedIn DustJS supports embedding javascript functions inside the render context itself. I will never be adding a javascript engine to this project, so those functions will not work in duster. I do have two plans to provide similar functionality:

  1. In the future I plan to officially support embedding rust functions inside your render context. I believe this functionality is already possible by wrapping your function inside a struct and putting your logic in the render function, but I’m hoping to provide a more standardized way to accomplish this.
  2. In the future I plan to attempt to compile this code to web assembly for running on the frontend. I assume this would also allow me to execute javascript using the browser’s javascript engine, but I have not looked into this yet.

Unicode support

The parser combinator library that I am using (nom) does not support unicode characters. In the future I will fix this, either by writing new parsers for the nom framework or by writing my own parser combinator framework. I’d prefer the former option since using a widely used parser combinator framework allows for greater interoperability across other projects (for example, if a nom-based html parser wanted to add support for parsing dust templates inside an text/x-dust-template tag, they could simply embed my parser inside theirs).


While this repository uses the 0BSD license which does not require the inclusion of a copyright notice/text in any distribution, it depends on some bsd-style licensed libraries including (but potentially not limited to):

  • the Rust standard library which is dual licensed.
  • nom which is under the MIT license.
  • serde which is dual licensed.
  • serde_json which is dual licensed but only used in the binary, not in the library

I am not a lawyer, and I am not your lawyer. This is not legal advice, but I believe attribution for these projects and their dependencies would be required under the terms of their licenses.