Node.js v0.10.42 is the latest in the 0.10.x release line, which was released on 2016-02-09, based on Node.js release history.
True, but meteor is still on 0.10.40 or now on 0.10.41 ā¦ neglecting anyhow the recent 0.10.42 security update 
. But dictating the node version in production anyhow.
I match it to .40 because from 0.10.41 on, npm will give you annoying version ahead warnings every time you use it. And as it has no impact on what meteor uses after all, it doesnāt matter.
The deployment buildpack that I use has a wildcard (requested_node_ver="0.10.*") to automatically download and install the latest Node.js version of the 0.10.x release line:
I had only known about the Node.js upgrade when I saw 0.10.42 in the log output:
-----> Downloaded app package (928K)
-----> Downloaded app buildpack cache (148M)
Cloning into ā/tmp/buildpacks/bluemix-buildpack-meteorāā¦
-----> Resolving engine versions
No version of Node.js specified in nodeversion, using '0.10.*'
Using Node.js version: 0.10.42
-----> Fetching Node.js binaries
- downloading and extracting node from http://nodejs.org/dist/v0.10.42/node-v0.10.42-linux-x64.tar.gz
Installing meteor
It appears to be working fine. So it may be OK to use 0.10.42 even though itās not officially supported.
Still some bugs I hope MDG can work out before final 1.3 release:
Iām going to assume the problem is not with the npm packages mentioned, since they work just fine in straight-up Node. And these are pretty popular packages, too.
Is it possible right now to release a package that would support ES2015 modules and would be compatible with Meteor 1.3 beta and 1.2? Iām developing v2 of jagi:astronomy package and I wanted to publish next RC version but I canāt after switching to ES modules. I get the following error: package.js:22:6: Object [object Object] has no method 'mainModule'.
No, features are up, but not downwards compatible. But what you can do is just use your favorite IDE and ācompileā your imports in to a single js file (potentially with some extra work). Than publish the two versions with the min/max meteor versions required field.
Or require people to use 1.3 anyhow, which I guess makes sense for a package like astronomy, to ānot encourageā globals.
Are you 100% sure? If itās true then Iāve made decision about moving to modules to early. I wanted to release Astronomy 2.0 before the end of Q1. Iām curious if MDG will be able to release Meteor 1.3 before the end of Q1.
1 Like
Hey Sam, could it be the npm packages are incompatible with the version of Node in Meteor?
Anyone get Typescript set up with Meteor 1.3 and React? Or even Blaze? Looking for a simple example. Thanks!
Been looking at thisā¦ but Iām stuck: https://github.com/Urigo/angular2-meteor/issues/102
Well, if you ask like that, donāt pin me down on itā¦ But following semver, and how that could even be technically possible (build tool change), I would be more than surprised. Like in the past, any 1.2 user could just run his meteor app on 1.3 - and be happy. That is the job of the version solver (working forward).
Regarding release: End of February is the latest (uncommitted) ETA. But this time, the 1.3 release comes quite packed with new features so there could be some unexpected delays. Just follow the github milestone (most issues are bugs).
Whatever you do, if I were you, I would embrace modules now and use beta 11 (!).
I sure as heck hope not. But itās possible. The AWS package makes a reference to __dirname which is supposed to be built into Node. The Stripe package, I have no idea why itās bombing.
If youāre right, then Meteor 1.3 should definitely not claim that you have access to all npm packages. Just most.
A lot of NPM packages that run on both node and in the browser do custom checks to detect if they are on node or not. Some check if require, __dirname, process, window or other globals are available and determine if they are on node or not. For example:
if (checkIfInNode()) {
require('http').get('/data');
} else {
$.get('/data');
}
But in Meteor this can break quite easily because the server and client are more isomorphic (if I can still use that term ;)) So this ticket can break a lot of the node checks in packages:
Is that a Meteor problem? Well, maybe, but weāll probably need to send out some PRs to fix the bad isNode checks in NPM packages. Maybe even add Meteor specific checks.
if (originalCheck || (Meteor && Meteor.isClient)) {
// do client thing
}
1 Like
I would say that if the packages work just great with Node and for everyone else, then yes, the issue lies with Meteor. It would be awesome to see this fixed.
Iām using at the moment 1.3 Beta 11 and works pretty good with all ES6 features. Good job!
You have done an amazing job guys! I āconvertedā a quite complex react webpack based app into a meteor 1.3 version and it worked (almost) out of the box!!!
The only thing I had to fix was adding the .jsx extension to the import statements (feature request 
).
This might solve your issue:
If Iām correct, this would still require you to change the .jsx extensions into .js, but the you can omit the extension in your imports. So still work, but no code changes 
Thanks! I think I prefer to have JSX files to have a jsx extension though. And I already made the changes anyway 
Is there a way to opt out of WKWebView / remove it. I know of at least one cordova plugin that simply doesnāt work with WKWebView yet. (cordova-google-maps)
@pmwisdom: Not currently. From this issue, it seems the incompatibility of cordova-plugin-googlemaps is with Cordova iOS 4 (which we use), not WKWebView specifically (so it wouldnāt work with UIWebView either).
Deploying a Meteor 1.3 app to my hosting provider (IBM Bluemix) fails. Is it because the release version is hardcoded as RELEASE="1.2.1" in the script at install.meteor.com?
Wouldnāt it be better if it could detect the exact version of Meteor that the app being deployed uses and install that?