This is great! Thou I think this should be implemented directly by the packages that use the Handlebars runtime. I'm doing that for hbsfy. It's much better that way because then the actual package using the Handlebars runtime can decide which version to use.

The hbsfy package was the reason why I created handlebars-runtime. This means that this package is now obsolete for me and I won't be no longer maintaining this. Although I see that there are few other packages on npm that depend on this:

https://npmjs.org/package/handlebars-runtime

If anyone wants to maintain this package I can give npm and github access rights.

The runtime access in hbsfy is implemented here:

https://github.com/epeli/node-hbsfy/blob/master/runtime.js

This is definitely feels cleaner, but is not intrinsically less brittle than what I've done here:

https://github.com/dlmanning/browserify-handlebars/blob/master/index.js#L8

In both cases we're exposing interior parts of another module that are outside our control. Longterm, this makes upkeep a pain.

Case in point, handlebars-runtime (and hbsfy) is currently incompatible with the latest version of handlebars, because @kpdecker has moved to using an ES6 transpiler.

The most ideal solution (that I can see) is for @kpdecker to maintain handlebars-runtime as a separate, but simultaneously released module. I know he's willing, and we're obviously all trying to implement our own stopgaps anyway.