Module Import Organization

announce
1

Hey all,

Piggy-backing off of my last post, I wrote up an article that outlines how I organize my method, publication and template imports.

I’ve found that without some basic organization, organizing these side-effect driven modules can quickly get out of hand. Using index.js files can help keep things modular and significantly clean up your client/mains.js and server/main.js files.

Hopefully this helps out the folks transitioning to modules!

3 Likes
2

your articles are always quality stuff, thanks :thumbsup: one thing I’ve never seen any recommendation on is imports structure for atmosphere packages. any chance you could write one up on that? it’s not even mentioned in the guide. I’ve been using something similar to the recommended application structure but it’ always felt a little odd in a packge

1 Like
3

Hey, thanks!

As far as importing Atmosphere packages goes, I usually just import them where I need them.

For example, if I’m defining a Blaze template in a module, I’ll be sure to import the Template object:

import { Template } from "meteor/templating";

Similarly, if I’m using the Roles package within a module, I’d be sure to import Roles from the `` package at the top of that module:

import { Roles } from 'meteor/alanning:roles';

You can find out which objects an Atmosphere package exports by looking at the api.export section of the package.js file.

If you’re using a package that works through side-effects, like accounts-password, there shouldn’t be any reason to import it into any modules. The Meteor build tool will ensure that it’s built into your final bundle for you.

4

oh I meant something similar to how the Meteor Guide recommends an application structure of file/folder organization. When writing an atmosphere package, you’ll end up with a lot of the same stuff as an application (server and client side code per feature, possible some UI elements, etc), but I’ve never come across a defined recommended file structure for atmosphere packages. Following the application structure recommendation always felt a little weird in a package

5

Gotcha. I can’t help much there. I honestly don’t write many Atmosphere packages anymore.

6

Here’s how we do it:

Top level directories are:

  • Objects in the system (e.g. users, tasks, etc. – typically mapping to collections)
  • Meteor-special directories like packages, private and tests.
  • A few other directories like lib, bin and build.

Generally, each object directory contains four things:

  • Some files that are used on both the server and the client.
  • A server, client and .admin directory for files specific to those environments.

Here, client is the enduser app and .admin is converted to a client directory in a generated project directory so we can have a second SPA for the admin side of the system. Typically files used on both the server and client have server- and client-specific code. These have the same name as the reused file and extend the object/class it creates.

main.js files live under top-level client, server and admin directories.

Packages are either simple, flat structures where a client.js and a server.js bring everything together if package.js alone isn’t enough -or- they are organized like the objects directories.