Add configurable renderer and drafts

[Ethan Reesor]

Feature requests:

• Allow configuration of the renderer
• Allow pages to be specified as draft
  • Draft pages should have _draft: true in their frontmatter
  • Draft pages will not be rendered unless configured (draft: true)

Impact:
The default behavior remains the same. The only issue would be if a developer is using _draft: true for another purpose in their frontmatter.

Patch:
To make these changes, apply the following patch, with the command git apply onessg.patch (the patch file must have a trailing newline or git apply will barf):

patch-package
--- a/index.js
+++ b/index.js
@@ -31,12 +31,16 @@ function processFile(filePath) {
   .then(middleware)
   .then(getDefaults)
   .then(data => {
+    if (data._draft && !conf.draft) return;
+
     // If _layout, render it:
     if (data._layout) return render(data);
     // Else, return _body:
     else return data._body;
   })
   .then(html => {
+    if (html === void 0) return;
+
     // Get path to write to using path-extra:
     var writePath = path.replaceExt(path.join(conf.dist, filePath), '.html');
     // Output using fs-extra:
@@ -72,7 +76,7 @@ function middleware(data) {
   case '.md':
   case '.markdown':
     // Render markdown:
-    return marked(data._body)
+    return (conf.renderer || marked)(data._body)
     .then(res => {
       // Overwrite data._body:
       data._body = res;

[Ryan Zimmerman]

Thanks for opening this issue!

onessg actually had _draft: true in an earlier version, but I removed it because I wasn't using it. I'm fine with adding it back, though. Just wondering, should drafts be compiled based on NODE_ENV?

I've been thinking it'd be good to have a configurable renderer; but I'm thinking it should somehow utilize jstransformer. Not 100% sure yet; I'll have to do some thinking here.

[Ethan Reesor]

Not sure. I've been using patch-package to capture tweaks I'm making to onessg for my environment. I'm using onessg with Gitlab Pages/Gitlab CI to generate static content. Some of my pages aren't ready for prime-time, so I added _draft: true to omit them from generation. I haven't had any need to actually build these files. I was thinking along the lines of hugo, which has a command-line parameter to include drafts. At this point, I could just change my CI config to only build the master branch and put my drafts in the develop branch or something; that would achieve the same results.

I think if drafts are compiled based on NODE_ENV, I should still be able to override that with configuration. I imagine that could be useful in a larger project.

I'm considering making a fork of onessg and building out the 'pipeline' into something more robust and configurable. And also something that would support selective recompilation, so I could watch for changes and only recompile a certain file.

[Ryan Zimmerman]

I've been planning to add a watch mode for a long time, but never got around to it.

A CLI flag does make sense for drafts.

I'm considering making a fork of onessg and building out the 'pipeline' into something more robust and configurable.

Mind elaborating? Any contributions that don't bloat onessg too much are welcome; I'm happy to add additional features to suit a wider audience.

[Ethan Reesor]

I'm not sure I can effectively explain with words; I'm better at explaining with code. I'll ping you when I have something.

Generally, I want to make onessg more flexible and extensible, while maintaining simplicity. So the default behavior would be identical. But if I want to go nuts, I can leverage it to create something much more powerful. So, instead of bloating it with lots of features, reorganizing the code to add extension points. Those extension points can then be used by the end-developer to add features.

[Ethan Reesor]

I've reimplemented the generation logic as a pipeline/middleware system. I put in a work-in-progress pull request: #54. Tests are not succeeding. I'm not sure why.

[Ryan Zimmerman]

See my thoughts here: #54 (comment).