Uncaught TypeError: Object #<Object> has no method 'merge' on version 1.0.12

[btakita]

1.0.11 works.

I'm using hbsfy (which uses handlebars-runtime) & browserbuild. When I try to invoke a template function, I get Uncaught TypeError: Object # has no method 'merge'.

Here is the compiled function:

function (context, options) {
      options = options || {};
      var result = templateSpec.call(container, Handlebars, context, options.helpers, options.partials, options.data);

      var compilerInfo = container.compilerInfo || [],
          compilerRevision = compilerInfo[0] || 1,
          currentRevision = Handlebars.COMPILER_REVISION;

      if (compilerRevision !== currentRevision) {
        if (compilerRevision < currentRevision) {
          var runtimeVersions = Handlebars.REVISION_CHANGES[currentRevision],
              compilerVersions = Handlebars.REVISION_CHANGES[compilerRevision];
          throw "Template was precompiled with an older version of Handlebars than the current runtime. "+
                "Please update your precompiler to a newer version ("+runtimeVersions+") or downgrade your runtime to an older version ("+compilerVersions+").";
        } else {
          // Use the embedded version info since the runtime doesn't know about this revision yet
          throw "Template was precompiled with a newer version of Handlebars than the current runtime. "+
                "Please update your runtime to a newer version ("+compilerInfo[1]+").";
        }
      }

      return result;
    } 

[kpdecker]

What version of handlebars-runtime?

[w33ble]

Getting the same via grunt-contrib-handlebars. For me, that was pre-compiling with 1.0.12 and using 1.0.0 on the frontend.

See gruntjs/grunt-contrib-handlebars#55

Seems to be something introduced in 1.0.12 as 1.0.11 still works.

[kpdecker]

@w33ble can you post a jsfiddle that demonstrates this?

[kpdecker]

or other publicly accessible resource :)

[w33ble]

1.0.12 -> https://gist.github.com/5698906
1.0.11 -> https://gist.github.com/5698920

https://gist.github.com/w33ble/5698906#file-templates-js-L7 is the offending line in the former

//1.0.11 version
helpers = helpers || Handlebars.helpers; data = data || {};

Became

//1.0.12 version
helpers = this.merge(helpers, Handlebars.helpers); data = data || {};

[kpdecker]

This is an expected change which unfortunately requires that you use 1.0.0 final runtime on the client. What does console.log(Handlebars.VERSION) say?

[w33ble]

I'm using 1.0.0-rc4. The Bower repo is behind :(

Grabbed 1.0.0 from the website and it does indeed work. I messed up when I tested that before. Thanks!

[kpdecker]

Ok cool. I've reached out to the guys who maintain the components/handlebars.js repo to try to get access to that so I can push to it as part of my release process.

Related: We've had a thread on versioning internally and our goal is to not introduce any more breaking changes between the runtime and the precompiler until version 2.0 and by that time we will hopefully have a much more automated way of pushing all of these out so there aren't as many places where the version numbers can lag.

[w33ble]

Sounds good to me ;)

This is just the result of a bad combination of timings I suppose. Had I just installed a fresh version of grunt-contrib-handlebars, or had Bower been updated, or if I was just grabbing libraries from websites, this wouldn't have even come up. That's just how she goes I guess.

Thanks for being on top of the issue though, it's appreciated.

[kpdecker]

We do include the dist file in the npm package. I'm moving my day-job
projects in the direction of using that so we never run into a version
mismatch. It doesn't always work for everyones build process but if it does
you should never have to worry about mismatch :)

On Mon, Jun 3, 2013 at 10:35 AM, Joe Fleming [email protected]:

Sounds good to me ;)

This is just the result of a bad combination of timings I suppose. Had I
just installed a fresh version of grunt-contrib-handlebars, or had Bower
been updated, or if I was just grabbing libraries from websites, this
wouldn't have even come up. That's just how she goes I guess.

Thanks for being on top of the issue though, it's appreciated.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/547#issuecomment-18849667
.

[erichiggins]

What's going on with this issue? What's the resolution? It's been blocking me for a few weeks now and I don't have time to shave yaks with workarounds. The additional issue of the bower version being out of date seems to be making matters worse.

[kpdecker]

@erichiggins use this with the 1.0.12 version of the precompiler and it should work.

[erichiggins]

Thanks @kpdecker. I tried that and it didn't make any difference.

[kpdecker]

Can you put up a jsfiddle demonstrating the failure?

On Sun, Jun 23, 2013 at 6:51 PM, Eric Higgins [email protected]:

Thanks @kpdecker https://github.com/kpdecker. I tried that and it
didn't make any difference.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/547#issuecomment-19885726
.

[erichiggins]

Unfortunately, no. The codebase is proprietary, and I don't have time to chop it up into a reasonable fiddle. The compilation step is handled by grunt-contrib-handlebars, but because Handlebars is inconsistent in it's versioning (1.0.0-rc4 vs 1.0.12, vs 1.0.0 for bower?) it's unclear which version it's being compiled with. claims to use ~1.0.10 in it's package.json.

[kpdecker]

I believe that is >= 1.0.10. npm ls | grep handlebars will tell you the
exact version installed.

https://github.com/wycats/handlebars.js/blob/master/release-notes.md has
our mapping between the unfortunately confusing versions. v* numbers are
node and those without are browser. The next release will unify the version
numbers as this has been a very common complaint.

On Sun, Jun 23, 2013 at 7:01 PM, Eric Higgins [email protected]:

Unfortunately, no. The codebase is proprietary, and I don't have time to
chop it up into a reasonable fiddle. The compilation step is handled by
grunt-contrib-handlebars, but because Handlebars is inconsistent in it's
versioning (1.0.0-rc4 vs 1.0.12, vs 1.0.0 for bower?) it's unclear which
version it's being compiled with. claims to use ~1.0.10 in it's
package.jsonhttps://github.com/gruntjs/grunt-contrib-handlebars/blob/master/package.json#L31
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/547#issuecomment-19885890
.

[erichiggins]

Ok, so here's what I've got then (thanks for that debug tidbit):

$ npm ls | grep handlebars
├─┬ [email protected]
├─┬ [email protected]

And handlebars.runtime.js contains:

Handlebars.VERSION = "1.0.0";
Handlebars.COMPILER_REVISION = 4;

Still no dice.

It's good to hear that the versioning is being resolved.

So, what's the state of 1.0.12 then? Is it considered broken as-is?
If so, why is it still unresolved?
If not, what can be done to correct this for the folks that this seems to be affecting (both here and elsewhere)?

Can more tests be added to avoid these types of issues in the future?
Can the FAQ be updated in the meantime to help others who are hitting this compatibility issue, so they don't have to search/dig to find an answer?

Thanks for the quick turnaround on providing assistance, though I'd really love to get the issue resolved so I can get back to work.

[kpdecker]

1.0.12 is considered working correctly as it passes all of the unit tests and we only have your report of being broken after version numbers are synced. I can't really help you debug this without actually seeing the output that you have. You can't pull out one template's precompiled output?

The versioning requirement is listed as a line item in the release notes: https://github.com/wycats/handlebars.js/blob/master/release-notes.md#v1012--100---may-31-2013

[erichiggins]

All of the templates are precompiled into one file. If it helps, here is the line where the error occurs:

...
 }, this.JST["app/tpl/layouts/main"] = function(a, b, c, d, e) {
    return this.compilerInfo = [4, ">= 1.0.0"], c = this.merge(c, a.helpers), e = e || {}, "<div id=content>\n  Main loaded.\n</div>\n"
} ...

Which throws Uncaught TypeError: Object #<Object> has no method 'merge'.

[kpdecker]

That looks like 1.0.12 proper output. And what are the contents of this when you run? The merge function is defined here and should be defined on this when run.

Also can you confirm that at runtime Handlebars.VERSION is 1.0.0?

[erichiggins]

Using a breakpoint, this seems to be a simple mapping of my templates (by path, to a function) -- that is, it matches this.JST as shown in the snippet above.

Handlebars.VERSION is, in fact 1.0.0, both at runtime and in the handlebars.runtime.js being used.

[kpdecker]

How are you calling your templates? Do you ever "reconstitute them" with the Handlebars.template call on the client side?

[erichiggins]

I'm using Marionette 1.0.3, which I've swapped out the default renderer with the following:

App.on('initialize:before', function(opts) {
  Marionette.Renderer.render = function(template, data) {
    return opts.JST[template](data);
  };
});

[kpdecker]

You need to use Handlebars.template to make the precompiled templates usable again. I'm a bit surprised that the templates worked previously actually.

Would need to do something like:

this.JST["app/tpl/layouts/main"] = Handlebars.template(function(a, b, c, d, e) {
    return this.compilerInfo = [4, ">= 1.0.0"], c = this.merge(c, a.helpers), e = e || {}, "<div id=content>\n  Main loaded.\n</div>\n"
})

If you want to use the render above.

[erichiggins]

Hmm, I wonder if something else had changed (in my code) which removed that snippet... Anyway, I'll give that a shot. Thanks for the help!

[creatorrr]

For bower installs that broke, the issue is in the handlebars bower component repo. It's still referenccing old dependency versions. Sent a pull request to fix it.

[luisjotapepe]

Any one know what is happening with this? I am running dev2.0 and get this.

I have [email protected]

I thank you kindly.

[luisjotapepe]

So i was able to temporarily solve the issue by replacing all encounters of line

helpers = this.merge(helpers, Handlebars.helpers); data = data || {};

with

helpers = helpers || Handlebars.helpers; data = data || {};

as suggested by @w33ble

Is there a better solution to this?

[kpdecker]

@luisjotapepe You need to match your precompiler and runtime versions. Precompiler of 1.0.12 and runtime of 1.0.0.

[adamwaite]

This is still happening with grunt-contrib-handlebars 0.6.0 and handlebars.runtime.amd 1.1.2 (both latest versions, in npm and bower) .

I can fix by using the command line utility for each template but it's quite laborious, i'd rather this be automated with grunt.

[kpdecker]

@adamwaite I'd raise this issue with the grunt-contrib-handlebars project directly, it sounds like there is still a version mismatch if that is what you are seeing.

[eden-lane]

Same problem with gulp-handlebars.
I'm using v. 1.0.12 for pre-compile and runtime v.1.0.0.
What I'm doing wrong ?

[kpdecker]

@EdenCore, if you can create a publicly accessible test case, preferable in jsfiddle or jsbin and file a new bug I can take a look. I suspect that there are unexpected versions on one side or the other.

[eden-lane]

@kpdecker sorry, I'm afraid I can't find a time for this in the near future. Right now I'm compiling my templates on the server side. Will try to reproduce this problem when I'll rewrite this part of code.