We’ve just released a new Meteor 1.3 beta, which combines the earlier modules and Cordova betas and now also includes a new version of the application testing changes that we’ve been working on.
Try the release by running meteor update --release 1.3-beta.12 in your app directory.
Please comment here if you have questions about how things are supposed to work. Open a GitHub issue about bugs that you find, or missing features that you need.
Meteor 1.3 gives apps full ES6 (ES2015) modules support and better NPM support. Apps and packages can now load NPM modules that are installed via npm install on client and on server. Amongst other benefits, modules let you control file load order in much more precise way than naming your files in special ways.
You can read a little about the way that the system works in the draft guide article (please excuse the incompleteness).
At the moment the system comes with some caveats as it is not quite complete – you can read about them on the ticket, but the main one is you can only use mocha tests using the avital:mocha reporter (a fork of practicalmeteor:mocha) as of this writing. We plan on working with popular testing package authors to change this very soon.
There are some specific things you need to make unit tests work properly with imports that the guide article will document soon, but you can refer to the tests in the Todos example app for now.
If you have specific issues or questions with the tests, it’s probably best to comment on the relevant issue for now.
@rhywden: I’m not sure what is going on, but it seems this might be related to issues with the package server. I noticed you already found the GitHub issue tracking this, so let’s continue the conversation there.
By the way, one thing I’ve noticed is Meteor adds its own Cordova plug-in but omits it from the .meteor/cordova file. It would be great if it would list it there, because then we’d know it’s there but default and can download the package to use from local source
Benefits would be 1) ability to modify package easily, 2) no need to re-download package each time you re-build 3) would always work offline.
Perhaps the Meteor plug-in could be added to the file manually and then linked to local file - I have not tried that yet.
I haven’t found more recent information, but this report suggests localStorage indeed maxes out at 10mb or even less depending on the OS and web view version. This isn’t Meteor or even Cordova-specific though, these are just the limitations set by the web view.
There are no improvements to offline persistence and data sync in 1.3. (Note that we don’t use localStorage for minimongo, data is just kept in memory.)
Yep, the plugin has been rewritten for both iOS and Android. The Android version wasn’t in an earlier beta, but it has been out for a couple of weeks now.
The reason the plugin isn’t listed in the .meteor/cordova-file is because it is a dependency of the webapp package. The plugin file is only used for plugins added at the app-level through meteor add cordova:<...>, not those added through Cordova.depends in a package.js.
I’m not sure I understand the benefits you mention. Independent of where a plugin is added, plugin download and installation is handled by Cordova. It always redownloads plugins downloaded from Git (which is where the plugin comes from right now), but caches those downloaded through npm. That does remind me I should release the plugin on npm, thanks!
Haha nice, glad that helped, and that Andriod made the cut.
Maybe I’m having an odd experience, but whenever I try to meteor run ios it ends up downloading the Meteor plug-in from git instead of caching it (on current v1.2). It usually takes a good minute or so depending on connection, but sometimes I don’t have a connection, so it makes it tougher.
For example, if I am connectionless and my Cordova build breaks due to a bad HCP, I’d have to re-run meteor run ios , then I have to pause work until I have a connection.
The allow-intent and allow-navigation tags are new for cordova-ios 4.x and greater, see the cordova-plugin-whitelist documentation for details. cordova-ios version 4.0 and greater does not require the cordova-plugin-whitelist plugin to be installed.
I have a Meteor app that utilizes the Braintree drop-in UI plugin for payment processing. The drop-in UI uses an iFrame.
I just tested the app with Meteor 1.3 beta 11 and found that without adding the allow-navigation directive manually to the config.xml of the cordova project, the Braintree drop-in UI would not function properly on iOS. It does work properly on Android.
So we should just use npm install to install npm modules.
That means we have to install node, that brings up the question: what version for it to work.
Meteor’s internal is 0.10.40 if I remember correctly.
Do we need to follow that, or any will work for us ?
I don’t remember where, but I had some issue with the newest node version (maybe building packages wrong or requireing incompatible ones). So I use n and switch to node v0.10.40 when ever working with meteor