Changed tmpl.render() to tmpl.renderToString(), cause in Marko v4 .render() returns a stream, not a string.
Fixed syntax in the test template.
Fixed one test ('should not cache by default').
Now, I don’t like the test fix. The problem was that Marko itself caches rather aggressively. You can tell it not to write compiled templates to disk, but even before looking for those, it looks in require.cache, and that behavior is not configurable.
My fix was to change expected readFile()/readFileSync() calls to zero. That was the minimal code change I’ve come up with, but it’s not semantic, and I’m not sure 0 calls are actually always guaranteed. Maybe we should skip both cache-related tests for Marko instead. Maybe we could go even further and turn off Consolidate.js caching for Marko.
And yes, we could also make a request to make Marko built-in caching optional, but I’ve no idea if they’ll accept it.
Turns out there’s already PR for that: https://github.com/tj/consolidate.js/pull/268. This one should probably be closed.
tmpl.render()
totmpl.renderToString()
, cause in Marko v4.render()
returns a stream, not a string.'should not cache by default'
).Now, I don’t like the test fix. The problem was that Marko itself caches rather aggressively. You can tell it not to write compiled templates to disk, but even before looking for those, it looks in
require.cache
, and that behavior is not configurable.My fix was to change expected
readFile()
/readFileSync()
calls to zero. That was the minimal code change I’ve come up with, but it’s not semantic, and I’m not sure 0 calls are actually always guaranteed. Maybe we should skip both cache-related tests for Marko instead. Maybe we could go even further and turn off Consolidate.js caching for Marko.And yes, we could also make a request to make Marko built-in caching optional, but I’ve no idea if they’ll accept it.