I would like to have all the helpers in handlebars-helpers - npm available for use in my .hbs files.
I did install it successfully using “yarn add handlebars-helpers”
but I get 400 error in my browser: [home.hbs] Missing helper: “eq”
when I use (e.g.)
{{#eq debug true}}
style=“color:blue;”
{{/eq}}
I get the same 400 missing error with each of the few helpers I have tries.
Am I misunderstanding something about the usage here?
That package was last published in 2017, as version 0.10. I don’t know if it worked with Ghost then (that’s well before my time!), but I’d be skeptical that it’d work without any fussing now.
If you’re interested in adding your own custom helper (which could only be done by patching the Ghost core, so not an option for anyone who isn’t self-hosting – you can’t just add one to your theme or in code injection), here’s the folder where the built-in helpers live:
Taking a look at how those are done is probably a good start on making your own new helper.
To your specific example: You don’t need an extra helper at all for what you’re trying to do. Here’s how to do it in Ghost (in a theme file - not in code injection):
{{#if debug}}
style="color:blue"
{{/if}}
Or if you’re not checking a boolean, you might also take a look at the #match helper, which does exactly what #eq does when given a “=” argument. (It can also be used for > or <.)
The documentation on the built-in helpers is not bad - you can find it here:
If there’s something you’re trying to do and can’t figure out, feel free to start a thread - there are lots of smart folks with sneaky tricks for getting the most out of handlebars.
An aside, because I’m not quite sure how you got to loading an alpha package from 2017, but I wonder if you get there via AI ‘help’: Because Ghost’s handlebars dialect is relatively unique, most AI programming tools seem to do a pretty poor job with it. I find that AI tools are generically much much better at Javascript and HTML than at Ghost’s handlebars dialect, probably because there’s just so much more of those languages in the training set.
I just used good old google to find all kinds of discussions about this over the years, no one seems to have come to a solution.
The reason many people have asked about this is because these provide basic but useful functionality to handlebars. Many of them are not available at all otherwise, and for those that are, the ghost way is an ugly code kluge that makes for hard to maintain hbs files. No one wants to make 20-block if/else statements 
I have seen the docs you linked. I see there are instructions on how to make one’s own helpers for ghost. It seems lots of people ask about these helpers.
So one solution is to port these to be custom ghost helpers. Probably doable by someone. Since the list hasn’t changed in a long time, maybe there is an argument to doing this and adding it to core ghost.
But that means if this npm package ever does change, someone will have to both notice and upgrade ghost. I don’t want to do that for my own project, and probably no other developer does either. If it is part of core, then at least we all benefit from one person doing it.
Another approach might be this, let me know what you think:
1 - install the helper package via npm to node_modules the standard way as I did
2 - modify gulpfile.js to see if the package is installed, if so, copy it to the folder where ghost wants custom folders to be
3 - modify core to see if these “custom” helpers are there, if they are register them the ghost way
The advantages to this are:
1 - it will pick up changes at the npm level meaning ghost developers will be using the original code in a ghost context, even of the package managers update the code
2 - the code changes to core are minimal and probably will only ever need to change if the list of helpers changes
3 - if the package is not installed, there is no change to ghost behavior or functionality
4 - it will “just work” if you install the package (there might need to be some decisions if there are helper name conflicts between ghost and the package, but that seems easy to fix, maybe by registering the names with a prefix
5 - this would provide a path forward for using other npm handlebars helper modules, and also for sharing custom modules among theme developers.
I need to move my project forward to alpha status asap so I am not going to do this immediately, but there will be a time when I need to refactor some stuff and if you think this will work, I might do the work and if I do get it to work, I would be interested in creating a pull request to get it into core because it’s a frequently asked feature request.
And maybe someone else will see this and give it a spin before I get to it.
Do you think this approach will work, and if it does it can be considered for core?
Is that package even maintained?
^^That’d be a question for the dev team.
A couple thoughts from me (not a member of the dev team, alas)
My $0.02.
Some code is so simple and just works that no maintenance is really necessary after a while. There’s a couple of packages like this, if this isn’t the latest one, then just replace what I said with the latest one.
Why should dev basically fork an existing code base and then deal with it? That kind of defeats the whole point of open source. And it won’t address the issue of how to use other handlebars modules from npm.