Recently I have been making a framework for both browser and Node.js. I couldn't find the best structure for both environment, so I went reading other frameworks, such as Meteor.

The build process of Meteor is something like this:

  • All JS files are automatically loaded
  • The order is specified here
  • Some files are included for only client / server side
  • It is not browserify, and you cannot use npm require on client side

Files in app are handled like this:

  • Every file is wrapped in a closure (function(){ ... })()
  • Local variables are file scoped
  • Or else you can declare variables in global scope like this name = 'value', without the var keyword, which is dirty
  • So you'll need workaround to make it works in strict mode

Files in packages are handled like this:

  • Local variables are file scoped
  • Global variables are package scoped
  • You can specify which variable(s) to be exported in package.js using api.export("someVariable")
    • Yes, it is a string, name of the variable, not a reference to the variable, because:
  • During the build process:
    1. Each file is wrapped in a clousure
    2. Meteor then scans your files to look for global variables declared in the name = 'value' style
    3. Add var name at the top of the closure to make then package scoped
    4. Add Package.<package name> = { name : name } to export variables
  • Any other way of defining global variable is not handled, you can easily create a true global variable by using eval.

It seems to me that Meteor is having a really big dream, it wants to change things from ground up, but JavaScript is not quite ready for that. The scoping mechanism is just a dirty workaround, just a trick on syntax quirks. There are ways you can declare a global variable in JS, they work the same, except one of them behaves differently only in Meteor.

Here is how it looks like: