How to best prepare for Meteor 1.3 and modules?

help
1

I’m about 40% through developing a SaaS, built on Meteor 1.2 and React. With 1.3 due out soon(ish), I’m wondering how I can best prepare for it. I know nothing about ES6 modules. Will this be preferred over creating several Meteor packages? Is there a sense of load order with modules?

1 Like
2

Being that this is a SaaS app that you want to get going (presumably) I would just keep the packages code as is, upgrade to 1.3 and add new code in as modules. As you have extra time, you can migrate a module over as you’d like. As it stands current apps will still use the normal load order by default and will have module load order if used.

The most basic migration will just be moving the foo.js file out of the packages folder and into the normal area. Then you can just import '../../foo' to resolve any load order issues. This leaves you with globals but they are at least not trapped in a package.


> Will this be preferred over creating several Meteor packages?

Times 100x. It’s much easier to share code this way and a lot less verbose.

Is there a sense of load order with modules?

Yep, this is the best part! If you import {foo} from '../foo.js' then the foo function would would be ready below that when you use it.

I’m about 40% through developing a SaaS, built on Meteor 1.2 and React. With 1.3 due out soon(ish), I’m wondering how I can best prepare for it. I know nothing about ES6 modules.

The great thing is that you can upgrade to 1.3 and continue using what you have and can then migrate one package module at a time over as it makes sense. Typically I only do this if i’m changing something in the module then i’ll refactor it, otherwise, it stays.

It really depends on the module and how far you want to take it. Here’s the minimum to get it working with 1.3 modules:

// mypackage/my-utils.js

MyUtils = {
  getThing: function(){
    return true
  }
};

Move this file out into a client/server/both folder in the root. I’m assuming MyUtils was exported from the package here. Now Meteor (currently) will load this in 1.3 with the same load order as before and it will expose MyUtils globally.

However, some files make error out because of a load order condition. Let’s say client/bar.js is using this module and it’s loaded too early and says MyUtils is not defined. We can just add an import like this:

 // or wherever we placed the file
import '../both/my-utils`

// 
MyUtils.getThing();

Notice we’re not importing the method like import {getThing} from '../both/my-utils', we’re just importing it so that the build tool can require it before the function is called below. This will just maintain the load order.

However, ideally we want to use a module and not expose a global. So we can modify our file like this:

//   /both/my-utils.js

const MyUtils = {
  getThing: function(){
    return true
  }
};
export default MyUtils;

// **or**
// more tersely:

export default {
  getThing: function(){
    return true
  }
};

Now we have a module but now any other code that depends on a global MyUtils will error out. You can then find/replace these areas and add this to the top of the file:

import MyUtils from '../both/my-utils'

MyUtils.getThing();

However, ideally I prefer to just import a function I need instead of the entire module namespace, you can do that like this (although for a migration this is more work, but you can do both too)

import {getThing} from '../both/my-utils'

getThing();

I’ll be making a screencast here in the next week to go over this a little more thoroughly but I guess this is the preview :smile:

7 Likes
3

Awesome, really helpful stuff! And yes, I’m really eager to get my SaaS launched ASAP, so I’ll just go back when I have free time and refactor.

Looking forward to that screencast!

1 Like