Migrating to Meteor 1.3

Awesome! Thank you sashko

Hey @sashko, can event maps not now be documented with the more concise function format? Ex:

'click #myButton' (event){}

instead of:

'click #myButton': function(event){}

Are there any breaking changes to the publish subscribe functions that may cause percolate:find-from-publication to break? Percolate:find-from-publication and Meteor.users

The Meteor guide documents them in this way, I’d be more than happy to accept a PR changing the docs as well (those live as a Meteor app in this directory: https://github.com/meteor/meteor/tree/devel/docs)

Do you think it would be cleaner/simpler for people? If so I’ll happily submit a PR

Absolutely! I think using the object method shorthand is definitely the right way to write events. All of the code samples in the Meteor Guide do it, I think we just haven’t taken the time to update the docs with all new ES2015 stuff. (see the Blaze guide article here: http://guide.meteor.com/blaze.html)

Modified /docs/client/full-api/api/templates.md and submitted PR. Removed all the other uses of function in that file while I was at it.

1 Like

I have been struggling to get my app to run in 1.3 I have Error: “There are no routes on the client or server” I have tried both Iron Router and FlowRouter, route definitions are not being pick up. I have tried place and import my router.js in almost every directory according to the new recommended app files structure.
Is there something I could be missing? What’s strange is the two examples leaderboard(1.2way) and todos-master(1.3way) both compile and work fine in 1.3.

A question:

In order to control load order of files, I put everything in packages.
Given the introduction of import and export, is there any benefit to having locally built packages now?

Two of the biggest reasons for the “packages for everything” approach were load order control and dependency management. Both of these can now be handled easily with 1.3. There could still be other benefits though, such as needing to manage multiple builds for different environments/platforms, or splitting out functionality into “microservices” (buzzword insertion complete), but most of the advantages are now baked right into 1.3.

Did you import your route definitions from client/main.js and server/main.js?

I have tried that also.

Is it safe to update my mobile app to Meteor 1.3 without refactoring all the code just to get the new Cordova Hot Code push performance?

1 Like

Yes, I think so (you mean refactoring to use imports?)

Yeah just by doing meteor update and keep the code as it is. No imports folder

1 Like

That should work perfectly! If it doesn’t, it’s a bug.

1 Like

Make sure and read the mobile breaking section in the Meteor guide. If you have mobile apps deployed through the Apple app store you will have to resubmit your 1.3 based app to Apple. You can not hot load an update to 1.3 from 1.2.

3 Likes

If you are using app-local packages to control load order and write
unit tests for your application, we recommend you switch to using
modules

What is the basic difference in local packages and modules. Does modules refer to NPM Modules. I had tried using import folder and files in my local package but got errors while importing. What is the exact recommendation for local packages?

What errors did you get? Yes the recommendation is to switch to imports and exports instead of local meteor packages, but you don’t have to switch all at once since the old system still works.

I have got error NPM package not found for my local files in import directory.