Meteor is an important patch for 1.4.2 users

If you’re currently using Meteor 1.4.2, it is strongly recommended that you run meteor update as soon as possible, and also meteor npm install --save babel-runtime, if your app does not already depend on that npm package.

As you can tell from the release notes, Meteor fixes a number of bugs, some of which may have prevented you from upgrading to Meteor 1.4.2, and even includes some further performance tweaks.

However, the urgency of this message comes from a specific issue with the Meteor babel-runtime package.

If you don’t care about the details, you can stop reading now and just run meteor update. In case you’re curious, I’ll try to explain what happened below.

If you’re running Meteor 1.4.2 and you happen to update just your packages (not Meteor itself), you will likely end up with babel-runtime@1.0.0, which is a new version of the Meteor babel-runtime package introduced by this pull request. Most notably, this version of the Meteor babel-runtime package now requires you to install the npm babel-runtime package in your app.

Relying on the npm version of babel-runtime is a good idea in the long term, but in the short term Meteor 1.4.2 still assumes that the Meteor babel-runtime package provides custom implementations of certain Babel helpers, such as babel-runtime/helpers/typeof and babel-runtime/helpers/createClass, and unfortunately ignores any helpers of the same names provided by the npm babel-runtime package.

Since version 1.0.0 of the Meteor babel-runtime package no longer provides any Babel helpers of its own, and Meteor 1.4.2 assumes that it does, babel-runtime@1.0.0 is effectively incompatible with Meteor 1.4.2, though it will work with any other recent version of Meteor, as long as you’ve run meteor npm install --save babel-runtime in your app.

It is tempting to release a babel-runtime@1.0.1 that provides the custom helpers that Meteor 1.4.2 expects, but that would defeat the purpose of switching to the npm version of babel-runtime, and delay everyone from arriving at a better solution. Upgrading to Meteor is the best solution available now.

Though it is the recommended solution, upgrading to Meteor is not the only way to work around this problem. The important thing is to avoid using babel-runtime@1.0.0 with Meteor 1.4.2. Another option would be to downgrade babel-runtime to the previous version by running meteor add babel-runtime@=0.1.12 in your app (note the @=). The drawback of this approach is that it prevents any future upgrades to the babel-runtime package, unless you remember to remove the @=0.1.12 version constraint from your .meteor/packages file. But if you really must continue using Meteor 1.4.2, downgrading babel-runtime will let you do that.

If you’ve read this far, I hope your curiosity is satisfied, and more importantly I hope you can avoid the problem and get back to developing your apps.


Thanks as always for the frequent updates and performance improvements!


Thank you. Keep up the good work!

Well, before it was working for me with 1.4.2, I had babel-runtime version 0.1.13. Now I did upgrade to but now I see babel-runtime 1.0.0 and meteor doesn’t start any more:

W20161110-10:47:39.012(1)? (STDERR) /home/max/src/mob/.meteor/local/build/programs/server/boot.js:348
W20161110-10:47:39.102(1)? (STDERR) }).run();
W20161110-10:47:39.102(1)? (STDERR)    ^
W20161110-10:47:39.103(1)? (STDERR) 
W20161110-10:47:39.103(1)? (STDERR) Error: The babel-runtime npm package could not be found in your node_modules 
W20161110-10:47:39.104(1)? (STDERR) directory. Please run the following command to install it:
W20161110-10:47:39.105(1)? (STDERR) 
W20161110-10:47:39.106(1)? (STDERR)   meteor npm install --save babel-runtime
W20161110-10:47:39.107(1)? (STDERR) 
W20161110-10:47:39.107(1)? (STDERR)     at meteorInstall.node_modules.meteor.babel-runtime.babel-runtime.js (packages/babel-runtime.js:37:9)
W20161110-10:47:39.108(1)? (STDERR)     at fileEvaluate (packages/modules-runtime.js:181:9)
W20161110-10:47:39.109(1)? (STDERR)     at require (packages/modules-runtime.js:106:16)
W20161110-10:47:39.110(1)? (STDERR)     at packages/babel-runtime.js:139:15
W20161110-10:47:39.110(1)? (STDERR)     at packages/babel-runtime.js:150:3
W20161110-10:47:39.111(1)? (STDERR)     at /home/max/src/mob/.meteor/local/build/programs/server/boot.js:295:34
W20161110-10:47:39.111(1)? (STDERR)     at Array.forEach (native)
W20161110-10:47:39.112(1)? (STDERR)     at Function._.each._.forEach (/home/max/.meteor/packages/meteor-tool/.1.4.2_1.scvu6x++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20161110-10:47:39.113(1)? (STDERR)     at /home/max/src/mob/.meteor/local/build/programs/server/boot.js:128:5
W20161110-10:47:39.114(1)? (STDERR)     at /home/max/src/mob/.meteor/local/build/programs/server/boot.js:344:5


meteor npm install --save babel-runtime


I did and:

max@loki:~/src/mob$ meteor npm install --save babel-runtime
npm WARN saveError ENOENT: no such file or directory, open '/home/max/src/mob/package.json'
└─┬ babel-runtime@6.18.0 
  ├── core-js@2.4.1 
  └── regenerator-runtime@0.9.6 

npm WARN enoent ENOENT: no such file or directory, open '/home/max/src/mob/package.json'
npm WARN mob No description
npm WARN mob No repository field.
npm WARN mob No README data
npm WARN mob No license field.

SOLVED. Stop Meteor, then install babel-runtime, then start meteor again.


Ran meteor update and got the following errors:

      throw error;

Error: EACCES: permission denied, mkdir '/home/my_project/.meteor/packages/aldeed_schema-index/.build878350..'

Tried to run as sudo meteor update, but it is suggesting that this is not what I want to be doing. Note: I made sure I used the suggested chown command following the attempt to use sudo meteor update.

I’ve followed the steps, but I’m still having the issue described here: Meteor not detecting new files

Sadly, I won’t be able to update to this version.

Looks like there is quite big performance issue with the latest meteor version. I just updated by executing these two commands:

meteor update
meteor npm install --save babel-runtime

With meteor 1.4.2 my node cpu usage when idle has been on OS X activity monitor between 2-3%. Now with latest cpu usage is between 4-6.2%. I’ve now downgraded back to 1.4.2 and the cpu issue went away.

My colleague also just installed the latest version on he’s windows 10 computer by running those two same commands and he’s cpu usage idle on 1.4.2 was 0-3%, now with latest it’s 5-10%.

We both inspected the cpu usage for around 5 minutes.

I have the same CPU issue on Windows 8.1

A simple 1.4.2 meteor app cpu usage was between 5-10%
after the upated to the same app cpu usage now above 50% and became very slow.

Are you noticing slower reloads or anything? It doesn’t really feel like a couple percent bump in CPU usage is that big of a deal in dev…

1 Like

I’m mostly afraid that this issue persists in production, that’s why I didn’t want to push the latest version to galaxy yet. Haven’t checked back with that yet.

Is there a command that I can pass to meteor to inspect the total build / reload times? If the cpu usage increase is just for dev and it increases the reload times, that sounds like a good tradeoff :slight_smile:

Having issues running that babel install… any ideas pls?

Also I am now getting security issues on Cordova app installed on my physical phone, have App.accessRules changed with this release??? It was working fine with 1.4.2 rc 2

For example, I have the following in my mobile-conflg

App.accessRule('https://**', { type: 'navigation' } );
App.accessRule('https://**', { type: 'navigation' } );
App.accessRule('https://**', { type: 'navigation' } );
App.accessRule('https://**', { type: 'navigation' } );
App.accessRule('https://**', { type: 'navigation' } );
App.accessRule('https://**', { type: 'navigation' } );

But I am getting lots of Failed to load resources from those domains. Again, this was all working fine with 1.4.2 on the document.on error…

Any thoughts appreciated???

BTW, my XCode seems to have been upgraded to 8.1, so not sure if some new setting in that as it seems to get running on my iOS emulator, so this just seems related to running on my physical devices (via lightning cable).

Same issue on Linux.
1.4.2 give me cpu usage around 4-6% is around 10-13%
@benjamn is it normal ?

Pls help, it seems to be stuck hours at ‘Extracting meteor-tool@1.4.2_1…’.

I have the same CPU issue on Linux.

You can try running METEOR_DISABLE_FS_FIBERS=false meteor to see if the CPU usage is related to the increased use of synchronous file system operations in Meteor—a performance optimization that has improved rebuild performance for many users.

Try METEOR_PROFILE=20 meteor, though that won’t measure idle CPU usage, just the timings of various parts of the build process.