render
render copied to clipboard
stdin (-) is not supported as the template path
$ cat template.js | render --engine swig --context package:package.json -
{ [Error: ENOENT: no such file or directory, open '-'] errno: -2, code: 'ENOENT', syscall: 'open', path: '-' }
It's actually https://github.com/tj/consolidate.js that reads in the template files, src/render.coffee
just passes on the path, or, in the case of -
, it passes on -
. Not really feeling like exploring the consolidate.js internals to see whether we can bypass its template file loader, to be honest. Left as an exercise for the reader? :)
Also, the README currently mentions that cat page.json | render page.jade
should work (to pass on data, not a template) but I think this was an aspirational thing on my part, it was never implemented (and will remove it from the README now).
I do feel that passing (often dynamic) data over standard input might potentially be more useful than passing in the (often static) template. Dunno what you think, @chocolateboy?
I do feel that passing (often dynamic) data over standard input might potentially be more useful than passing in the (often static) template.
In my use case, I'm splitting the input file into a header template and a static body and sending the header through render:
target/head.js:
$(HEAD) input.js | render - --engine swig --context context.json --output $@
target/body.js:
$(TAIL) input.js > $@
Either way, I would expect -
to work anywhere a path is accepted. IMO, it's a standard CLI feature, rather than something the application should have an opinion on.
For now, I've worked around this issue by using tmpin:
$(HEAD) input.js | tmpin render --engine swig --context context.json --output $@
Yeah, no objections regarding the -
convention. Just not high priority enough for me to tackle.
It looks like consolidate
has support for rendering strings, not just files.
consolidate.pug('foo.pug', {}, function(err, output) {/*...*/});
consolidate.pug.render('a string of pug', {}, function(err, output) {/*...*/});
EDIT: I originally included a table listing the engines that did and did not support rendering strings, but then I realized they all supported it.