Add ability for Selleck to use a custom Handlebars object #12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is take 2 of my original pull request that allowed for handlebars helpers to be tacked on to the Handlebars object.
#9
There were multiple problems with that approach, mostly because the Handlebars object is global and cannot be overridden per-component, the semantics of loading a custom config that could itself require dependencies was hairy and so on.
This PR inverts the model and allows the user to pass in
--handlebars <path>
option.path
is thenrequire
-ed in selleck and used to update theHandlebars
object in place, early before any rendering is done.Thus, as long as the module provides an object that is compatible to Handlebars, it will work seamlessly and the user now has the option to associate all sorts of helpers applied at a "system" level.
The advantages of this approach are:
There is now an implicit coupling between the markup in the docs and the helpers needed to render them but this is treated as user problem and not a selleck problem.
If you guys like this approach, I will move forward and add tests and such otherwise I'll just keep building my docs out of my fork :)