Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the require system instead of copy/pasting the generated runtime. #3

Closed
wants to merge 1 commit into from

Conversation

kamicane
Copy link

The package now depends on Handlebars and requires the needed parts for the runtime only, producing the generated runtime at runtime.

This way, both browserify (and similar tools!) and the handlebars-runtime package can use the same Handlebar installation, avoiding potential version conflicts.

The package now depends on Handlebars and requires the needed parts for the runtime only, producing the generated runtime at runtime.

This way, both browserify (and similar tools!) and the handlebars-runtime package can use the same Handlebar installation, avoiding potential version conflicts.
esamattis added a commit to esamattis/node-hbsfy that referenced this pull request Nov 3, 2013
We'll now use the handlebars module directly. Thanks to @kamicane

esamattis/node-handlebars-runtime#3
@esamattis
Copy link
Owner

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

@dlmanning
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants