The trick: Minimize the need for an @INC or build system by using the browser's existing capabilities.
jsan.js gives you an include() function similar to what Torgo's bootstrap.js is doing, it just relies on the browser's own "script" tag. This include function does what you'd expect and a little more. It looks in some sensible local locations for the file, the URL the HTML file is in (./js/foo.js) and the document root (/js/foo.js). The exact locations searched for could be configurable in something like
use(): Now the fun begins. Notice how its
remote libraries: If I want to distribute something which depends on other modules you don't have to install those dependencies to use it! My code says "use('something')" and it gets loaded from the net if necessary. If you want to install the dependencies locally, you can. You don't even need to install anything, you can just reference JSAN directly. Fantastic for rapid prototyping.
To avoid jsan.org being a central point of failure, even with mirrors and round-robin DNS, a set of mirrors would be built into
versioning: Ovid's the one who figured all this out. Local versioning is a little problematic, but remote versioning is a snap. Watch.
Versioning on the local filesystem is a bit harder, and you'll see why an integer versioning system is used. Going with an only.pm installation style where modules get installed as module-version/ so wibble-13/. How do you find the latest version of something when you can't ls? You also don't want to have to load a module just to find out its the wrong version, you want to continue down the INC path.
Here's the best I've got at the moment. When you install a JSAN module it goes into a module-version/ directory. It also writes/adds to module/manifest.js which is just a list of what versions of the module are installed. Essentially a hard-coded ls. use() can then employ that list to figure out if the right version is installed or if it has to look further up the INC path.
The problem with that is it makes installing a JSAN module more than simply unpacking a tarball or zip file. I'd rather not have a build system at all, introduces cross-platform scripting nightmares.
One thought is that, largely, this versioning stuff is YAGNI particularly having multiple installed versions of the same module and modules which need a particular version. So perhaps each module would have a simple version.js file which jsan can load and examine to get the version without having to load the whole module. Then you can just install as module/ (ie. no version in the directory name) and go. Those few who really want multiple versions installed can do the module-version/ and module/manifest.js scheme which requires extra build/install magic.