What are the Meteor core modules?

help
1

I’m working to get changes made to the atom-import-js plugin for the Atom editor that will improve it’s effectiveness in generating correct import statements within Meteor projects. It is just a shell around the npm importjs package. So the changes will actually happen in importjs and should benefit users of Atom, Emacs, Sublime, Vim or any other editor with an importjs plugin.

One of the things importjs does (optionally) when automatically creating the needed imports in your module is to group them into imports from core packages, other packages, and modules.

In order to accomplish that, one of the things it needs to know is what the “core” modules are. It currently only knows “node” modules and this knowledge is activated by specifying "environments": [ "node" ], in .importjs.json. It then refers to an internal list of “node” modules.

I’m going to do a PR to add a list of “meteor” modules so that we can specify "environments": [ "meteor" ], and get the same effect. That’s the simple part. The hard part is coming up with the list.

I found a one page copy of docs.meteor.com and used some sed magic to dig out all of the “import” statements shown in function headers and somewhat double checked by examining all of the packages in the Meteor project’s packages directory for api.exports statements that didn’t appear to be for internal use to come up with the following list.

  meteor: [
    'meteor/accounts-base',
    'meteor/blaze',
    'meteor/check',
    'meteor/ddp-client',
    'meteor/ddp-rate-limiter',
    'meteor/ejson',
    'meteor/email',
    'meteor/http',
    'meteor/check',
    'meteor/meteor',
    'meteor/mongo',
    'meteor/random',
    'meteor/reactive-var',
    'meteor/session',
    'meteor/templating',
    'meteor/tracker',
  ],

Note that I left jquery and underscore off because I’ve seen indications they may be coming out of core.

So, I’m looking for both opinions and actual knowledge here… Anything

  • missing?
  • present that shouldn’t be?
1 Like
2

Core modules for meteor are in the packages dir of the project. Some of these may not be relevant to what you are trying to accomplish, but I think it’s a good starting point.

3

Thanks. That’s actually somewhat what I did though I used my locally cloned meteor copy. I updated my post to make it clearer.

A lot of what I found in there appeared to be internal or undocumented edge cases. Part of what I’m looking for is whether I was right or wrong in ignoring the ones I ignored.

I wish the package system had a way of specifying what is a “public” export versus something like a “protected” one, but that is a separate topic.