Environments Entry for "meteor"

I second @awatson1978 in saying “thank you, thank you for putting this together”!

To complement #288, I am investigating other aspects of getting this package to play really nice with Meteor.

Though node.js is a part of meteor under the hood, what we see as our “core” modules is quite different. As a start to get the groupImports feature to play nicely with Meteor, I’d like to request an addition to the supported “environments”. I am currently vetting my list of what I believe are Meteor’s “core” modules on their forum, but believe it will be close to the following:

  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',
  ],

Would you be willing to accept a PR for this?

Also, I have several other ideas on the burner for things like

• automatically identifying our 3rd party packages (that middle group in groupImports),
• easing our extensive use of namedExports (unlike NPM, our package system defines the exports so we have the leg up you were discussing in #107 for this one),
• exposing babel-lint’s “allowImportExportEverywhere” option to us (we’ll need to turn it on),
• and handling the common usage of the import for side-effects statement in Meteor (import './thisModulesName.http;' and import './thisModulesName.css';).

As well as thoughts about the configuration processing (love the idea of accepting a js file and wonder if that could be expanded on a touch to allow plugins that specify things like above for different environments). Should I approach these via more “issues” or a more general offline discussion followed by more issues?

[rhettlivingston]

I’m mostly afk for another few weeks though as I’m building a house.

Totally understand. I have about 3 months of house repairs on the back burner myself.

As you’ve already discussed, I’m a little concerned about the complexity of grouping. Going back to straight alphabetic ordering (no groups) is tempting, although I recognize that grouping has been important for some organizations to adopt import-js as a tool. Would it be terrible to disable grouping for the meteor environment to begin with until we have time to enhance it?

As someone who implemented this type of automatic grouping of imports all the way back in the early '90s for other languages in large-scale development projects, I can attest to the craziness that can go into these coding standards in organizations.

Currently, without this and other changes we’ve discussed, the imports do come out as one big sorted group in Meteor. So, no need to disable. That’s where we are at. Anything we do will just improve on that situation.

I think we can get a clean and flexible implementation of the grouping with minimal change. In reviewing your code, it mostly seemed to be a matter of generalizing what is already there. Moreover, I think I could work most of its aspects in parallel with javascript configurations. The js configuration capability merely expands its usefulness (an order of magnitude perhaps).

Anyway, no harm in a strawman. If we’re not happy with it, I imagine it will be easy to adjust it till we are.

[rhettlivingston]

The original issue spawning this thread was resolved by 526c3d0 which was merged to master by 629e49b. Other issues have been created to address thoughts in the above dialog.

Closing this issue.