Where all Meteor imports are defined?

Every http://docs.meteor.com/#/full/ article has line with the following structure:

import { Meteor } from ‘meteor/meteor’ (meteor/client_environment.js, line 49)

As far as I understand, all imports are loaded somewhere at startup and exported somewhere first. Where can I see both exports and imports, which constitute Meteor?

See the guide: http://guide.meteor.com/v1.3/structure.html

Thanks for lightning-fast answer.

Just 2 points I do not understand:

  1. My old app is working after ‘meteor update’ to 1.3 without import { Meteor } from ‘meteor/meteor’ present anywhere.
  2. New todos scaffold:

import { Meteor } from ‘meteor/meteor’; for server

import { Template } from ‘meteor/templating’;
import { ReactiveVar } from ‘meteor/reactive-var’;

for Blaze templating.

So these are bare import minimum for any Blaze-based app?

Yes, 1.3 is designed to be backwards compatible. The imports folder is for all the imports and exports that are not eagerly loaded but are imported into the app as you define. The imports on your point 2, is for files that are in the imports folder.

I see. A moment ago I have deleted all 3 imports from my point 2 and it still works :slight_smile: Truly backwards compatible.

So at the moment its use is more of informational value so that non-Meteor devotee can just tell… “aha… that’s where this Meteor variable comes from”.

I’m using

import { Meteor } from 'meteor/meteor';

within the imports folder when within that file I’m using a Meteor api like

Meteor.isServer
Meteor.call
Meteor.loginWithPassword
1 Like

Kind of, but it’s not just informational. If the import line is present, then it guarantees the source. So if at a later stage, a different global variable of the same name is introduced, the file won’t break.

It also means, moving forward, that you don’t need to resort to crazy names to get files to load in the right order, makes the code easier to test, analyse and work with, also with tools from the wider ecosystem and potential future improvements. e.g. you could never do “tree shaking” (like e.g. rollup.js) by relying on globals. So it’s a big improvement for us :slight_smile:

2 Likes