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
- present that shouldn’t be?