Загрузчик модулей для node js с поддержкой локальных модулей и загрузки модулей по требованию

Его сложно найти :-) github.com/nin-jin/node-jin#autoloader

1. При использовании fibers можно и асинхронно грузить файлы. С другой стороны, синхронная загрузка файлов быстрее асинхронной.
2. Exception в любом коде уронит ноду, если не завернуть его в try-catch или domain.
3. А что там может быть не то? Любой нормальный модуль при загрузке ничего не делает — просто предоставляет некоторый объект, так что там и падать-то особо не чему. Разве что модуля может не оказаться, но это лишь малая доля ошибок. Куда большая часть ошибок в том, что модуль неправильно функционирует, а чтобы это понять нужно прогнать тесты, а не просто загрузить его.

Никто не запрещает вам подключать модули, как и раньше подгружая их в шапке файла, например, вот так:

var {
		lodash,
		gulp,
		webpack
	} = require('sp-load');

И не будет никаких проблем. Полагаю, вы согласитесь со мной, что пример выше, как минимум выглядит посимпотичнее, чем:

var lodash = require('lodash'),
	gulp = require('gulp');
	webpack = require('webpack');

С ростом кол-ва зависимостей в файле это становится заметнее. Согласен, что это мелочь, но все же. И да, es6 деструктуризации
еще нету в ноде, если запускать ее без каких-либо флагов, но будущее уже совсем рядом.

Смысл подключения модулей по требованию(lazy load) в том, что, например, если вы работали с gulp-ом, то
вы знаете, что при запуске gulp-а происходит инициализация различных тасков, например, таска запуска юнит тестов,
таска сборки проекта, таска минификации js-а, css-а и т.п. и т.д. Так вот, например, вы хотите запустить
таск минификации css. Для минификации нужен всего один галп плагин — gulp-cssmin(с названием могу ошибаться, но
не суть), так вот скажите мне зачем для минификации css-а тянуть модули karma для юнит тестов, модули для минификации
js-а, модули для сборки проекта, модули для чего угодно, но не для css минификации? Не знаете? Вот и я не знаю, зачем.

Если вы говорите, что подгрузка всех этих модулей не влияет ни на экономию памяти, ни на производительность, то
скажите, пожалуйста, почему у модуля gulp-load-plugins 15 000 скачиваний за сегодняшний день и сотни модулей,
которые зависят от модуля gulp-load-plugins? Я не пытаюсь как-то оскорбить вас, но, думаю, что среди тех людей, который
обеспечили 15 тысяч скачиваний этого модуля за сегодняшний день, есть не глупые ребята и просто так бы использовать
его не стали?

Ну и последнее — в моем модуле есть поддержка локальный модулей, это основная «фича», ради которой и задумывался этот модуль.
Не нужно писать относительные или абсолютные пути к файлам проекта. Определив их в "_localDependencies", затем работаешь с ними,
как с обычными сторонними модулями из node_modules, то есть обращаешься по имени модуля, например,

$.myDeepLocalModule().

Опять же, если вам не подходит по какой-либо причине загрузка локальных модулей по требованию, присвойстве их в шапке
файла:

var {myDeepLocalModule} = require('sp-load');

Если вы прочтете вот эту статью https://gist.github.com/branneman/8048520, то увидите хронологию этой проблемы с локальными модулями,
она обсуждалась много лет назад и до сих пор обсуждается, в этой статье собраны все текущие «хаки», решающие в той или иной мере
эту проблему. Мне кажется, что мое решение этой проблемы гораздо удобнее, нежели предложенные в этой статье.