Никто не запрещает вам подключать модули, как и раньше подгружая их в шапке файла, например, вот так:
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, то увидите хронологию этой проблемы с локальными модулями,
она обсуждалась много лет назад и до сих пор обсуждается, в этой статье собраны все текущие «хаки», решающие в той или иной мере
эту проблему. Мне кажется, что мое решение этой проблемы гораздо удобнее, нежели предложенные в этой статье.
И что самое важное — я не нашел такого решения на npmjs.com, посему оформил все это в свой модуль. Не претендую на авторство различных алгоритмов, просто сделал и опубликовал.
Да, читал. Основа того, что описано в этой статье взята из gulp-load-plugins, тонее сам алгоритм. Тот же алгоритм. В своем модуле я также заюзал этот подход, но есть несколько дополнительных особенностей в моем модуле:
1) Добавлена поддержка локальных модулей
2) Не нужно подключать sp-load и производить какие-либо инициализации, вызов require('sp-load') возвращает уже сформированный объект, содержащий модули по требованию
3) Вся информация о модулях, будь то локальных или внешних хранится в package.json-е проекта.
и т.д.
И не будет никаких проблем. Полагаю, вы согласитесь со мной, что пример выше, как минимум выглядит посимпотичнее, чем:
С ростом кол-ва зависимостей в файле это становится заметнее. Согласен, что это мелочь, но все же. И да, 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, то есть обращаешься по имени модуля, например,
Опять же, если вам не подходит по какой-либо причине загрузка локальных модулей по требованию, присвойстве их в шапке
файла:
Если вы прочтете вот эту статью https://gist.github.com/branneman/8048520, то увидите хронологию этой проблемы с локальными модулями,
она обсуждалась много лет назад и до сих пор обсуждается, в этой статье собраны все текущие «хаки», решающие в той или иной мере
эту проблему. Мне кажется, что мое решение этой проблемы гораздо удобнее, нежели предложенные в этой статье.
1) Добавлена поддержка локальных модулей
2) Не нужно подключать sp-load и производить какие-либо инициализации, вызов require('sp-load') возвращает уже сформированный объект, содержащий модули по требованию
3) Вся информация о модулях, будь то локальных или внешних хранится в package.json-е проекта.
и т.д.