You’re reading the ZotLit v2 docs. Still on v1? Read the v1 docs

ZotLit

JavaScript templates

What the JavaScript Templates gate enables, why it exists, the risks of opting in, and behavior when disabled.

JavaScript templates is a per-device gate that controls whether Eta templates compile and execute. It is disabled by default.

What the gate enables

A template document declares its language in its own text, not in its filename. A citation text or partial carries a manifest with the single key language: eta; a profile document sets its language on the Name and folder tab. See Profile document for the manifest and the frontmatter entry members.

When JavaScript templates is on:

  • Eta template documents compile and execute using the Eta engine (full JavaScript).
  • Managed frontmatter entries written with the js member evaluate their expressions.

When disabled (the default):

  • Eta documents are inert: never compiled, never executed.
  • Only Liquid documents and expr or value frontmatter entries are active. An expr entry holds a Liquid expression and a value entry holds a JSON-e template.

See Behavior when disabled for the exact failure mode.

Why it exists

Liquid templates render text. A Liquid template has no way to open a file it was not given, make a network call, or run a system command. It can only combine the data it receives into output.

Eta templates are full JavaScript. Code in an Eta document runs with the same access as ZotLit itself: it can read and modify your vault, connect to the internet, and on desktop, access your system. A template document copied from a forum post, a shared vault, or another device executes with that full access the moment it runs.

The gate keeps this boundary explicit. Liquid stays safe by default; JavaScript execution requires a deliberate opt-in.

Risks of opting in

Security implications

Only enable this if you trust every Eta template document in your vault. Eta templates are not audited or sandboxed by ZotLit.

Once enabled:

  • Every Eta template document in your template folder executes without further prompts.
  • A template from an untrusted source could read files, make network requests, or modify your vault.
  • The consent is one-time per device. It covers all current and future Eta templates.

Per-device scope

The consent is stored on the device itself, outside the synced plugin settings. Enabling it on one device does not enable it on another. Each device where you want Eta templates to run requires its own opt-in.

If you sync your vault across devices, only devices where the owner has explicitly enabled the setting will run JavaScript templates.

No plugin reload required

Toggling the gate takes effect immediately. ZotLit rebuilds the template folder in place, no reload needed.

Behavior when disabled

When the gate is off and an Eta template document would otherwise render, ZotLit treats it as inert:

  • The operation that needs the template (create note, update note, insert citation) fails with an error naming the cause. There is no silent fallback to the built-in default.
  • Settings > ZotLit shows a warning: The Eta template at … is inactive because JavaScript templates are disabled on this device.
  • The document remains in your vault untouched, never compiled.

The same applies to a managed frontmatter entry declared with the js member. A note write that consumes such an entry fails, and the error names the inactive fields. ZotLit never writes a partial field set, so existing notes stay unchanged.

Coexistence with Liquid

A template document declares one language, so a Liquid document and an Eta document never compete for the same name.

A ZotLit 2.1 name could carry both a .liquid.md and an .eta.md file. While both exist, the Liquid file wins and the Eta file is ignored, whether or not the gate is on. See When two 2.1 files share a name.

See also

Last updated on

On this page