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 client.coffee:
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.