npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2025 – Pkg Stats / Ryan Hefner

ostache

v0.1.0

Published

Templating language for structured data

Downloads

13

Readme

O-Stache

Build Status

This is a simple adaptation of mustache style templates to structured data (as opposed to plain text/HTML). Of course, you can use mustache templates to generate structured data, but you lose the ability of JSON/YAML/etc. tools to easily validate it, and the ability to convert the template between different structured formats (e.g. JSON -> YAML -> HOCON -> ...).

It is currently at version 0.1 - there are some tests, it seems to work, but it hasn't yet been used in anger, it lacks documentation, and there are known sharp edges (e.g. see Errors below). Feedback welcome.

How it works

Refer to tests.json for a comprehensive view of how everything works.

The module exposes a render function of the form:

function render (template, parameters)

where template is some arbitrary structured data, and 'parameters' is an object containing values that can be addressed via the template.

The output of the function is the rendered structured data, and will be identical to the input template except where ((...)) is used. This is interpreted as an ostache command (cf mustache with {{...}} - we use ((...)) for better YAML compatibility).

Basic variable substitution

Any time ((variable)) is used, the variable is looked up in the parameters (or the current context) and inserted into the string or object. If parameters[variable] contains structured data, this structured data is retained only if the variable substitution is the only element in the string.

For example:

template:
  y: "((x))"
parameters:
  x: {z: 1}
result:
  y: {z: 1}

Or, inside a string:

template:
  y: "hello ((x))"
parameters:
  x: "world"
result:
  y: "hello world"

Unlike mustache, no HTML escaping is performed.

If one is referring to parameters inside a nested structure, '.' can be used as the separator (e.g. one could refer to x.z to obtain the value 1 in the first example above).

Conditional includes

...automatically look in outer scopes...

Loops

Defaults

Because users can provide arbitrary structured data, when constructing the template it is sometimes useful to provide 'default values'. This can be achieved in some cases by having the defaults at the top level of the object structure along with the conditional includes; for example:

Overrides (forbidden values)

... precedence tricks ...

Errors

Unlike ordinary mustache templates, it is possible to create templates that are unparseable, largely because of the possibility of generating incompatible types from multiple conditional includes (or if one has other fields in the base object). For instance:

parameters:
  x: true
  y: true
template:
  val: "hello"
  ((#x)):
    val2: "bye"
  ((#y)): "never"

Here, although the ((#x)) inclusion resolves to an object/map (e.g. one can add val2 to the top level fields), because the inclusion of ((#y)) resolves to a string, it is unclear how that should be 'added' to the object. The general rule is that if there is any non-object type here, that should be the only type. It would be valid to do:

parameters:
  y: true
template:
  ((#y)): "never"

which would simple evaluate to the string "never".

For the moment, these errors are simple assertion failures generated by the node 'assert' module. A better error handling scheme is planned.

Err, XSLT?

No comment.

Why are the tests in some weird json format?

The intent is to be able to use these tests to check the compliance of o-stache libraries implemented in other languages.

See also

  • Googler's hyper-complex version of this: http://jsonnet.org/
  • Mozillians' slightly less complex version of this: https://taskcluster.github.io/json-e/
  • CloudFoundry's version abandoned due to complexity: https://github.com/mandelsoft/spiff
  • Something that is really quite close to this (and if I had known...): https://selecttransform.github.io/site/

You can also use json query languages to build arbitrary structured outputs (i.e. they can generate templates where the parameters are the input, and the query is effectively the template). A non-exhaustive list:

  • https://stedolan.github.io/jq/
  • http://jmespath.org/
  • http://goessner.net/articles/JsonPath/
  • http://objectpath.org/