Open watson opened 1 year ago
Pinging @elastic/kibana-security (Team:Security)
I would also be interested in seeing if Handlebars would accept these improvements upstream as a runtime option: https://github.com/handlebars-lang/handlebars.js/issues/1934
Any update on this?
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.)
@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.
@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 https://github.com/elastic/kibana/pull/138957.
The recommendation is to split the package out into a new repository.
For those looking, I created a kibana fork to publish kbn-handlebars
: https://www.npmjs.com/package/kbn-handlebars
https://github.com/davidfant/kibana-handlebars/commit/e3e925c9ee5b4d7f3a8cc60e3b7c202841490490
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:
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:
So as I see it, the upsides of releasing this to npm far outweighs the theoretical downsides.