Open firelizzard18 opened 6 years ago
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.
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.
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.
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.
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.
See my thoughts here: https://github.com/RyanZim/onessg/pull/54#issuecomment-346042886.
Feature requests:
_draft: true
in their frontmatterdraft: 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 orgit apply
will barf):