Can anyone give me a quick rundown on how to properly import modules on Meteor?

help
1

Let’s say I install a random Meteor package to use on my React-Meteor project.

How do I know the path of the module? For example, an arbitrary package called MyPackage…

import myPackage from "xxxxx";

How do I know what to type in place of “xxxxx”? When importing react, I simply just write “react” and when import Meteor, I have to type in “meteor/meteor”.

I just don’t see any consistency here and would like to know how to know the correct way to import modules, no matter which one I download.

2

For Meteor packages the rule is 'meteor/creator:package-name'. For MDG packages (like reactive-var), the creator: part is omitted, so 'meteor/reactive-var'.

Basically, it’s exactly what you see in atmosphere with meteor/ at the front.

2 Likes
3

Thanks for this Rob.
Something I was struggling with just today.
I was getting errors that said moment is undefined.
So I need to: import meteor/momentjs:moment yes?
(I have already added the package via meteor add momentjs:moment)

4

TBH I’d recommend removing moment:momentjs and using the npm moment package directly.

meteor npm install moment --save

and then import it where you need it with import moment from 'moment';

But you could certainly try sticking with the moment:momentjs package and see if import { moment } from 'meteor/moment:momentjs'; works.

5

Thanks again Rob.
I’ll give it a go when I’m back at work tomorrow.

1 Like
6

Hey Rob, thank you for the helpful reply.

I see below you said you would prefer NPM packages directly over Atmosphere? Do you recommend that for everything or just select cases?

7

“Everything” is not currently possible, nor is it always desirable. Generally speaking though, in Meteor 1.3+, I would go with native npm modules. There is an argument for stability with a wrapped atmosphere package, but all too frequently that’s just a euphemism for “abandoned”. I still make exceptions for core Meteor packages (which is pretty obvious, I guess!) and a number of useful atmosphere packages which offer genuinely useful functionality (like astronomy, for example).

8

I know this is an old topic but something important I dealt with this week… if you decide to use the NPM version of some packages by doing:

meteor npm install moment underscore --save

And you use certain Meteor packages that haven’t been modernized like iron:router, aldeed:autoform, edgee:slingshot, tap:i18n, even some native Meteor packages like mongo, spacebars, mdg:meteor-apm-agent they will still have dependencies on the Meteor/atmosphere versions of underscore and/or moment.

So if you install the NPM version for general usage in your app, you’ll wind up with two versions in your client bundle. The NPM version you chose and installed and the Meteor/atmosphere version required by all those packages.

It’s best to do a meteor list --tree and see if your packages depend on the Meteor/atmosphere underscore or moment (you can also just look at your versions file and see if those are listed). If so, I would recommend using the Meteor/atmosphere version of those common packages so you only have one version bundled to your client. It’s kinda backwards but it’s the only way to not ship double packages (unless you fork packages and start doing some hot-rodding).

Also, if you installed an NPM package that depends on underscore or moment (run meteor npm ls to check) then you’re screwed. You’ll have to ship two versions. That is until the Meteor underscore package gets updated like the jquery package to reference the NPM version of the package and complain in the console if it’s not installed.

1 Like