xDoT

Small, fast and powerfull temlate engine - online demo

This engine is based on doT.js by Laura Doktorova @olado

Differences from original package dot@beta:

• TypeScript syntax
• Arguments definition (inc. destructured) in tempalte: {{:{foo,baz}=foo+baz}}
• Nested templates with parameter supported: {{##nested : {foo,baz} :foo+baz#}}
• Recursion with nested templates supported
• No whitespaces before and after line blocks {{## }}, {{# }}, {{? }}, {{~ }}
• Extra block {{-}} to remove whitespaced before and after
• Object iteration supported: {{~~it :value :key }}
• Removed delimiter configuration globally via SetDelimiters
• Strip option is false by default
• Option selfContained removed. All encoders are self contained.
• Options internalPrefix and encodersPrefix are replaced by varName and defsName
• Jest tests instead of Mocha

Features

• Runtime evaluation and interpolation
• Compile-time evaluation
• PartiNested templates support
• Conditionals support
• Array/Object iterators
• Control whitespace - strip or preserve
• Streaming friendly
• Typescript syntax support out of the box
• No dependencies, can be used in nodejs or browser

Installation

npm install xdot --save

Usage

Nodejs

import { template } from 'xdot'

const t = template("<div>Hi {{=it.name}}!</div>\n<div>{{=it.age || ''}}</div>")

console.log(t({ name: "Jake", age: 31 }))
// <div>Hi Jake!</div>
// <div>31</div>

Security considerations

xDoT allows arbitrary JavaScript code in templates, making it one of the most flexible and powerful templating engines. It means that xDoT security model assumes that you only use trusted templates and you don't use any user input as any part of the template, as otherwise it can lead to code injection.

It is strongly recommended to compile all templates to JS code as early as possible. Possible options:

• using xDoT as dev-dependency only and compiling templates to JS files, for example, as described above or using a custom script, during the build. This is the most performant and secure approach and it is strongly recommended.
• if the above approach is not possible for some reason (e.g. templates are dynamically generated using some run-time data), it is recommended to compile templates to in-memory functions during application start phase, before any external input is processed.
• compiling templates lazily, on demand, is less safe. Even though the possibility of the code injection via prototype pollution was patched (#291), there may be some other unknown vulnerabilities that could lead to code injection.

Contributing

When contributing, keep in mind that it is an objective of xdot to have no package dependencies. This may change in the future, but for now, no-dependencies.

Please run the unit tests before submitting your PR: npm test. Hopefully your PR includes additional unit tests to illustrate your change/modification!

License

MIT