Как стать автором
Обновить

Комментарии 17

Нельзя выкатить новую версию модуля под видом старой — мало ли что вы там поломали в новой. Поэтому npm publish требует увеличивать версию.
Благодарю за ответ.
Наверное Вы это читали, но все же оставлю ссылку на эту статью.
Да, читал. Основа того, что описано в этой статье взята из gulp-load-plugins, тонее сам алгоритм. Тот же алгоритм. В своем модуле я также заюзал этот подход, но есть несколько дополнительных особенностей в моем модуле:
1) Добавлена поддержка локальных модулей
2) Не нужно подключать sp-load и производить какие-либо инициализации, вызов require('sp-load') возвращает уже сформированный объект, содержащий модули по требованию
3) Вся информация о модулях, будь то локальных или внешних хранится в package.json-е проекта.
и т.д.
И что самое важное — я не нашел такого решения на npmjs.com, посему оформил все это в свой модуль. Не претендую на авторство различных алгоритмов, просто сделал и опубликовал.
Я три раза перечитал статью, но так и не понял какую проблему решает автор.

1) Много require в начале файлов -> создайте отдельный файл который будет возвращать объект с уже подключенными модулями и используйте его везде.
2) В чем смысл подключения модулей в nodejs только тогда когда они нужны? Экономии по памяти не выйдет, а лишняя логика добавляется, да и в некоторых ситуациях это может вызвать тормоза для первых обращений к таким методам.
3) Чем не устраивает стандартный метод «резолва» модулей через NODE_PATH?
Здесь ещё вот какой момент. Вызов require — синхронный. Так как он отложен и будет вызван неизвестно когда, скорее всего его вызов попадётся в асинхронном коде. Что доставляет следующие неприятности:
1. Ожидание файлового ввода-вывода, что порочит идею асинхронного кода.
2. exception в этом коде уронит ноду (приятной отладки).

Вызов синхронного кода во время работы сервиса (не консольной утилиты) — это всегда зло. Поэтому загружаем все модули на старте и если что-то не то, получаем просто не загрузившееся приложение, что быстро диагностируется и лечится.

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

Зачем это?
Согласен, профита тут мало получится. Это затем, чтобы не грузить всё подряд, а только то, что реально используется. И чтобы не следить вручную за портянкой require. И чтобы вообще эту копипасту не писать.
Никто не запрещает вам подключать модули, как и раньше подгружая их в шапке файла, например, вот так:

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, то увидите хронологию этой проблемы с локальными модулями,
она обсуждалась много лет назад и до сих пор обсуждается, в этой статье собраны все текущие «хаки», решающие в той или иной мере
эту проблему. Мне кажется, что мое решение этой проблемы гораздо удобнее, нежели предложенные в этой статье.
1) Если у вас один конфиг на все случаи жизни, который работает по разному в зависимости от условий, то вы сами себе создали проблему. Я не знаю какие там проблемы у gulp и зачем он вообще нужен вместе с webpack'ом.
2) За все время работы я не сталкивался с проблемой написать полный путь к нужному мне файлу, а вот с проблемой таких хитрых загрузчиков сталкивался. С ростом приложения, все эти хитрые загрузчики только осложняют жизнь.
3) Объясните мне для чего нужны локальные модули?
Вот по этой ссылке рассказывается для чего нужны локальные модули.
Я видел, для меня это не проблема. Во первых это очень редкие случаи, а во вторых имеется нормальная поддержка IDE. В третьих если вы не пишите модуль, то проблему решает NODE_PATH.
Это очень частые случаи, когда вы пытаетесь хорошо структурировать своё приложение. Перенесли скрипт — извольте поправить все относительные ссылки.

Собственно по ссылке:
4. The Environment
Setting application-specific settings as environment variables globally or in your current shell is an anti-pattern if you ask me. E.g. it's not very handy for development machines which need to run multiple applications.

If you're adding it only for the currently executing program, you're going to have to specify it each time you run your app. Your start-app command is not easy anymore, which also sucks.
Похоже что автор придумал сам себе проблему, и героически ее решил)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.