React support would be really interesting. I'm not sure what the JSX AST looks like, but with a little clever pattern matching I think this could be doable. Here are some potential stumbling blocks off the top of my head:

• AFAIK, React components must return a single element. So we'd either need to enforce that relationship strictly, or detect (with an HTML parser? ugh) whether a template contains more than one top-level element and wrap in a <div></div> accordingly.

• You can't arbitrarily wrap attributes or open and close tags in conditionals in JSX; dynamic attributes must be set with attr={value}, and conditional nesting is more complicated.

• Conditional attributes in particular would require detecting patterns like attr="{{ value }}", class="static {{ dynamic }}", or class="{% if x }}x{% else %}y{% endif %}" and transforming to JSX-compatible expressions (attr={value}, class={`static ${dynamic}`}, and class={x ? `x` : `y`}, respectively).

• Mapping from template variables to props might be tricky. This looks like a pretty straightforward transformation from:

  <ul>
    {% for link in links %}
    <li><a href="{{ link.href }}">{{ link.text }}</a></li>
    {% endfor %}
  </ul>

  to:

  export ({links}) => {
    return (
      <ul>
      {links.map(link => {
        return <li><a href={link.href}>{link.text}</a></li>;
      })}
      </ul>
    );
  };

  But does the component necessarily get {links: links}, or the links array as props? Do we have to detect all of the "top-level" template variables so that we can generate the right destructuring expression?

One nice thing, at least, is that we wouldn't have to worry about whitespace and could just pipe the generated code through prettier. ✨

What if you could use meta-template to figure out all of the variables a given template expects? All of the following should be theoretically possible to figure out from the AST:

• You can derive top-level variable names from statements like {% if foo %}, {{ foo }}
• You can reasonably assume that foo is an object with an optional bar property from {% if foo.bar %}, or expressions like {{ foo.bar[0] }}
• You can infer arrays from loops like {% for x in foo %}
• Conditional statements could suggest whether certain data properties are optional; whereas a "naked" expression like {{ foo }} suggests that foo is required

The other way that this could work is as a validation tool in which you would provide, say, the JSON Schema for the data a template expects (which would serve as the template's "API"), and then validate a template against that schema to confirm that it doesn't attempt to access invalid properties, attempt to iterate over primitives, etc.

The trick will be getting this to work with the new integration tests, since services like Travis and Circle can be tricky to get working with multiple language environments.

It might be worth considering a one-time conversion from the Nunjucks AST to unist so that it would be easier to write utilities for modifying them.

Currently, Nunjucks' raw filter doesn't produce an AST node that we can use to easily map to the equivalent escape tags in other templating systems:

$ echo '{% raw %}{{hi}}{% endraw %}' | ./bin/parse.js -ct

produces:

{
  "children": [
    {
      "children": [
        {
          "value": "{{hi}}",
          "type": "TemplateData"
        }
      ],
      "type": "Output"
    }
  ],
  "type": "Root"
}

It looks like what we have to do is check if each TemplateData node's value contains any of the format's O_OPEN, O_CLOSE, C_OPEN, or C_CLOSE strings, and escape it accordingly. This actually makes more sense because the delimiters will vary by engine, so ERBs can escape only the values they need to.

The simplest thing here would probably be to have a script that runs a standard set of converted templates (the feature lower common denominator) through a reference implementation of the target engine (ideally a shell one-liner) to ensure that we get the expected output. For instance, we might test the Handlebars conversion with a this, which we might call handlebars:

#!/usr/bin/env node
const fs = require('fs');
const op = require('yargs').argv;
const template = fs.readFileSync(op.template);
const data = JSON.parse(fs.readFileSync(op.data));
console.log(
  require('handlebars').compile(template)(data)
);

which the testing script could call with a diff.sh that looks something like:

#!/bin/bash
# transform the fixture template with the input format
meta-template fixtures/$(1)/template.njk -f $(2) \
  | ./bin/$(2) --data fixtures/$(1)/data.json \
  > fixtures/symbol/$(2).txt
# then diff it against the fixture's expected output
diff fixtures/$(1)/{output,$(2)}.txt

which you'd call with:

./bin/diff.sh symbol handlebars

(or do it in Node.) The layout might look like:

test/
├── fixtures
|   ├── lookup
|   |   ├── data.json
|   |   ├── template.njk
|   |   └── output.txt
|   └── symbol
|       ├── data.json
|       ├── template.njk
|       └── output.txt
├── bin
|   ├── diff.sh
|   ├── handlebars.sh
|   └── liquid.sh
├── handlebars.spec.js
└── liquid.spec.js

@dsingleton, do you have any thoughts on this?

It should be possible to generate a matrix of support for specific features from a set of Nunjucks template snippets. For instance, these roughly map to the more common AST node types:

symbol:  '{{ foo }}'
lookup:  '{{ foo.bar[1].baz[0][1] }}'
literal: '{{ true }}'
filter:  '{{ foo | bar }}'
# maybe for Mustache's {{}} vs. {{{}}}?
escape:  '{{ foo | escape }}'
if:      '{% if foo %}foo{% endif %}'
# there is no Else or ElseIf node type, but these need their own tests:
else:    '{% if foo %}foo{% else %}bar{% endif %}'
elseif:  '{% if foo %}foo{% elseif bar %}bar{% else %}baz{% endif %}'
unless:  '{% unless foo %}bar{% endunless %}'
for:     '{% for x in foo %}foo {{ x }}{% endfor %}'
include: '{% include "foo.html" %}'
block:   '{% block foo %}foo{% endblock %}'
extends: '{% extends "foo.html" %}{% block foo %}foo{% endblock %}'

I think it'd be really cool if meta-template could batch-convert a collection or "suite" of templates into a supported format, and use knowledge of templates' inter-relationships to convert them in more reliable and useful ways.

For instance, in order to "correctly" convert templates that use {% extends %} to Jekyll layouts, you need to put those in the right directory (_layouts vs. _includes). Most templating systems (including Liquid, which Jekyll uses under the hood) just want a bucket of files in a single directory, but Jekyll and some CMS-specific engines assume a bit more structure. I guess for Jekyll it's possible that a "suite" of templates could be output to a site's (or theme's) _includes directory and that the layouts could {% include %} the appropriate page templates?

I added custom tags to use in nunjucks templates, how can I add them to those recognized by the parser ?

In Nunjucks and Jinja, the macro tag is the closest we can get to functional programming with templates, and is a much clearer and succinct way of handling defaults than the convention of components or partials expecting specifically named, global template variables. For instance, to create a nested list component without macros, you end up doing something like this:

<ul>
  {% for item in links %}
  <li><a href="{{ item.href }}">{{ item.text }}</a>
    {% if item.links %}
      {% set links = item.links %}
      {% include 'list.html' %}
    {% endif %}
  </li>
  {% endfor %}
</ul>

...which is clunky and brittle because:

1. As a user of the component or partial, you have to find the for loop in order to know that it expects the links variable to be set, and trust that none of your other templates reference that variable.
2. If the component maintainer has to change the variable name for whatever reason, all of the templates that reference it need to be changed, too.
3. The include needs to reference the full path to the template within the environment path(s).

The solution is something much more elegant:

{% macro list(links) %}
<ul>
  {% for item in links %}
  <li>
    <a href="{{ item.href }}">{{ item.text }}</a>
    {% if item.links %}{{ list(item.links) }}{% endif %}
  </li>
  {% endfor %}
</ul>
{% endmacro %}

I'm not sure what compatibility would look like for other languages, but here's a first pass:

1. Jekyll could do this with include parameters, e.g. {% include list.html links=item.links %}

2. ERB might be tricky because I'm not sure if it's valid to define a function and break it up with delimiters like this:

    <% def list(links) %>
      <ul>
      <% for item in links %>
        <li>
          <a href="<%= item.href %>"><%= item.text %></a>
          <% if item.links %><%= list(item.links) %><% end %>
        </li>
      <% end %>
      </ul>
    <% end %>

3. Twig has macros, but PHP would need to look more like ERB.

4. I'm pretty sure that Handlebars would require registering a helper in JS. ☹️