Release @kbn/handlebars to npm

[watson]

I think it would be a great idea to release our version of the handlebars (currently named @kbn/handlebars) to npm under the name @elastic/handlebars.

The reasons are:

1. More eyes on the source code means more secure and less buggy source code.
2. Great opportunities for conference talks and blog posts about why we made it, how we made it, and how it can improve the security of other peoples applications.
3. Giving back to the community is just the right thing to do.

I often hear that we don't want to release a piece of code to npm because it gives us an extra maintenance burden. However, I think this is completely wrong because:

1. As long as we still use it ourselves it's in our own best interest to maintain it.
2. If a user asks to have a feature added which we don't require ourselves, we don't have to comply. It's our project and we choose what to include in it. There's nothing wrong with that.
3. If we stop using it ourselves and feel the burden of maintaining it for others is too big, we can either:
   • Move it to a community maintained org on GitHub and invite collaborators to take it over.
   • Just deprecate it. We're not required to maintain something forever just because we once made it public.

So as I see it, the upsides of releasing this to npm far outweighs the theoretical downsides.

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

I would also be interested in seeing if Handlebars would accept these improvements upstream as a runtime option: handlebars-lang/handlebars.js#1934

[u873838]

Any update on this?

[djahandarie]

Thank you so much for doing this. We use this in our MV3 extension yomitan (no eval is allowed). It'd be great if you could package this, as it'd make our build process much cleaner. (FWIW, I think it's more ideal for us as a fork, as the eval is clearly eliminated from the codebase that way.)

[legrego]

@elastic/kibana-operations what is the best way for us to proceed? Changing the namespace to @elastic instead of @kbn is straightforward, but do we have precedence for publishing modules to npm which reside within the Kibana monorepo? It seems like we don't have any @elastic-namespaces packages in the repo anymore.

One-off publishing may be easy enough to accomplish, but having a dedicated workflow to follow would be best for long-term sustainability & security.

[jbudz]

@elastic/kibana-operations what is the best way for us to proceed? Changing the namespace to @elastic instead of @kbn is straightforward, but do we have precedence for publishing modules to npm which reside within the Kibana monorepo? It seems like we don't have any @elastic-namespaces packages in the repo anymore.

We don't, it's not supported under the current packaging workflow. The remaining elastic namespace packages were removed in #138957.

The recommendation is to split the package out into a new repository.

[davidfant]

For those looking, I created a kibana fork to publish kbn-handlebars: https://www.npmjs.com/package/kbn-handlebars
davidfant@e3e925c