Meteor 1.8.2-beta.17, ReferenceError: meteorBabelHelpers is not defined

I’m using Meteor 1.8.2-beta.17, and running into the same issue described here. It seems this is a result of @benjamn’s PR, Move meteorBabelHelpers to modules package, but more likely the fault of the peerlibrary/meteor-subscription-scope package which has a for-in loop in coffeescript.

Issues related to babel/transpilation/legacy-bundles are a little over my head at the moment, but what is the proper way to solve this?

I’m using an up-to-date version of Chrome if that’s relevant: Version 76.0.3809.132 (Official Build) (64-bit)

Thanks for your help!

update: I just put up this PR which solves the problem locally for me, but perhaps it isn’t the most correct solution. @mitar maybe you can help out here.

I suspect your app may be loading a cached version of the package which is compiled slightly differently to what’s expected after the commit you’ve linked.

Try removing the cache from .meteor/packages/peerlibrary_meteor-subscription-scope/ and performing a meteor reset to force it to re-compile?

Hmm. Thanks for your suggestion! Unfortunately I still get the same error after taking those steps. Let me know if there’s any other information that would be useful.

I suppose my confusion stems from the fact that on the one hand, I’m not using a legacy browser, so it makes sense that after the meteor PR meteorBabelHelpers is not defined, but on the other hand, peerlibrary/meteor-subscription-scope seems to require meteorBabelHelpers since it throws an error on line 25 of

for field of res when field.lastIndexOf('_sub_', 0) is 0

with Uncaught ReferenceError: meteorBabelHelpers is not defined

Perhaps benjamn’s discussion on this issue here can provide more insight:

The meteorBabelHelpers namespace is used for only one thing: meteorBabelHelpers.sanitizeForInLoop , which is used to sanitize objects looped over by for - in loops so that those loops behave the same way in all browsers.

So I’m guessing you’ve got a .coffee file with a for - in loop enclosed by backticks.

Given this analysis, although you could still solve this by depending on babel-runtime , the coffeescript package should really api.imply the same runtime environment that ecmascript provides.

There aren’t any back-ticks in this case, but the two scenarios do seem suspiciously similar.

hmm, I wonder if it’s because peerlibrary:subscription-scope has api.versionsFrom('METEOR@');

If you make a local fork and update the versionsFrom, does it help?

Otherwise it might be the coffeescript compiler :man_shrugging:?

Thanks again for the suggestion @coagmano - still no luck unfortunately. The only thing that’s worked so far so converting the loop.

That’s unfortunate. Seems like such a strange error

For posterity:

1 Like