emport v0.6.4

                           emport.js

A module-like packaging system for javascript and coffeescript source files that target the browser.

This is an early beta release. Use at your own risk etc. See /examples folder for usage example.

                              ---

Hey what about requirejs(.org) and AMD? Have you heard about those?! They do the thing that this thing does!

emport.js makes some different tradeoffs from require.js, from reading http://requirejs.org/docs/why.html, we are in agreement with everything up until "First thing to sort out is a script loading API"

emport.js is the result of asking "what if we ditch the script loading API?". We still want our individual javascript files to look like modules. At the top of the file we want to see the interface the module exports and what other modules it depends on. Those are good things. And it's obviously a good idea to use that information to generate the Giant Concatenated Source String that gets sent to down to browsers. But other than that it should be browser-side programming just like the old days with our old friend:

(function(){
  
  this.MyModuleName = function() ...
  
}).call(this);

... he's done good by us. Coffeescript users don't even have to type the closure because coffeescript is javascript's best friend.

What does it look like?

Here is an example (coffeescript) source file header pulled from an app running in production that shows what using emport.js looks like in practice:

#@export GoalListView

#@import Backbone
#@import $
#@import $.fn.chosen
#@import $.fn.sortable
#@import records
#@import goalListItemView

class @GoalListView extends Backbone.View
  ... class implementation ...

As you can see the import and export directives are just comments with a specific syntax. If you decide to give up on modularizing your client-side js and just go back to The Way It Was then nothing will break. You just delete the comments and your code is exactly how it used to be.

Does emport.js throw an error when a module tries to access a global variable it has not imported?

Currently no, but that seems like the right direction to head.

Why would I want to put all these stupid boilerplate import and export comments everywhere?! This just seems like extra work! Haven't you used Ruby on Rails? What's wrong with just assuming that every source file has access to all the rest of the code in the project automatically?

Yes. Modularization at the source file level is not every developer's cup of tea.

                              ---

Some other projects that occupy the same general vicinity as emport.js that you may also be interested in:

r.js - node.js based library and command line tool for packaging js source files that use the requirejs module system https://github.com/jrburke/r.js

Sprockets - Rack (Ruby) based, does dependency-aware concatenation of js source files and many other things too. Built into Rails 3.1 https://github.com/sstephenson/sprockets