Refactor template compilation

[sethkinast]

OK, there are quite a few changes in here.

This is the first step towards treating compiled templates as first-class citizens in Dust. We want to be able to pass around compiled templates and render them without having to worry about registering them under a specific name.

• dust.render and dust.stream now accept a compiled template function in addition to a template name.
• dust.compile no longer requires a template name, and will compile an anonymous template without one (so --name is no longer required for dustc either)
• dust.load is removed from the public API
• dust.compileFn is removed completely
• dust.renderSource is moved to the compiler, so it's only included in dust-full now (Fixes Remove reliance of functions in dust.js on dust.compile #412)
• add dust.isTemplateFn
• add dust.config.cache = true, set to false to disable caching and load templates again every time (Fixes caching is unavoidable #451)
• add dust.config.cjs = false, set to true to compile templates as CommonJS modules for use like:

var dust = require('dustjs-linkedin');
var tmpl = require('tmpl/foo/bar.js')(dust);

tmpl({}, function() { ... });
dust.render(tmpl, {}, function() { ... });
tmpl.template // function body_0(){ ... }

• add --cjs flag to dustc
• Move a bunch of exposed compiler stuff under dust.compiler (but leave it exposed until 2.8)

Fixes #349 indirectly.
Closes #330 indirectly. require.extensions is deprecated and the Node team recommends it not be used. The supported use case is going to be requiring compiled templates if you want, and hydrating them with a reference to Dust. This also lets you use multiple Dusts if you want, which is cool. Dust is not going to concern itself with how you load a template-- that's what dust.onLoad is for.

[sethkinast]

This will force a 2.7.

[sethkinast]

Ugg I actually really really don't want to leave dust.compileFn in, because it will leak into dust-core.

Isn't that the purpose of cutting a 2.7? I kind of want to push back on this one. @jimmyhchan

[sethkinast]

Updated to leave all the dust.* stuff from the compiler in until 2.8.

It's also under dust.compiler.* because that will be its new home.

[sethkinast]

Meh https://github.com/search?p=4&q=dust.compileFn&ref=simplesearch&type=Code&utf8=%E2%9C%93

Let me see if I can write compat behavior that makes it part of the compiler.

[sethkinast]

OK I'm happy again. It's part of the compiler now, and it's simpler too thanks to the changes.

It should still be removed eventually.

[sethkinast]

Added CommonJS tests.

[sethkinast]

@rragan would you mind taking a look to see if this supports PayPal's use case? I made many of these changes to specifically try to address how you guys use Dust.

You can compile a CommonJS module:

$ bin/dustc --cjs tmp/tmpl/**/*.dust --pwd=tmp/tmpl
├── hello.dust
├── hello.js
└── one
    ├── world.dust
    └── world.js

Now, you can require one of those modules, and hydrate it with a dust (this lets you add in the helpers you need first etc)

var hello = require('./tmpl/hello.js')(dust);

hello is a function that accepts (context, callback). It also has a property template that contains the compiled Dust template. So then you can do any of these:

hello(ctx, function(err, out) { ... });
hello(ctx).pipe(res);
dust.render(hello, function(err, out) { ... });
dust.stream(hello).pipe(res);
hello.template // function body_0(chunk, context, bodies, params)...

[sethkinast]

Yes, we'll need to work with them to update their code.