Речь больше про будущие возможные ядра систем сборки, и конкретно про bem-tools 2.0.
Случай 1. Когда кол-во плагинов и модулей на проекте разрастается до 30-50, которые будут друг друга реквайрить внутри, то загрузить их достаточно быстро, но инициализировать будет долго. Например, чтение большого проекта будет подвисать, когда как для некоторых команд, типа создания блока, это будет лишним, поскольку достаточно будет только информации об уровнях и технологиях по умолчанию.
Случай 2. Асинхронные реквайры позволят делать всякую магию с автодогрузкой модулей при необходимости и частичной сборкой.
Случай 3. Проверка обновлений в bg с выводом сразу, если возможно, либо со складыванием в кеш и последующим выводом.
И еще один тезис. Если вы скажете, что это никому не нужно — то вы заранее отбираете у потенциальных пользователей эту возможность, что делает ядро сильно менее универсальным. Завернуть что-то единожды при разработке плагина, во что-то типа modules.define или прописать ему зависимости и реализации, не такая уж крупная потеря, но потерять возможность делать асинхронщину много хуже.
Хочется, конечно, послушать и ваши доводы по этому поводу.
Есть такое мнение, что хорошо решать реальные задачи, а не реальные решать не хорошо =)
У тебя есть каких-то жизненных примеров, когда всплывают проблемы со случаями, которые ты описал выше?
Основная проблема в предлагаемом тобой подходе, на мой взгляд, не в том, что придётся поменять синтаксис, а в принципиальных отличиях.
requireв ноде явно привязан к файловой системе,requireвymсовсем не знает что такое файлы. Из-за этих отличий в ноде нельзя доопределять, но можно использовать сразу несколько вариаций одного модуля, и наоборот вymдоопределять можно, а вот несколько вариаций одного модуля нет.Надеюсь, я донёс мысль, что это два диаметрально противоположных способа работы с модулями. Поэтому давай чесно определимся чего же хочется на самом деле: асинхронности или доопределений и переопределений?
У меня скрипт есть, который делает fetch и cd, чтобы при переходе в проект
git statusсразу показал чего есть новенького. Не надо было бы — не предлагал бы ;-)И не надо. Сейчас есть require, файлы и их экспортируемые properties. А будут ym, плагины (зависимостями), и их контракты. Эта абстракция, по сути, ничего не забирает, просто меняет подход и позволяет делать магию внутри себя.
Несколько версий одного модуля — это решаемо. Если это не забытый и кривой депенденс, который стоит обновить asap, то это никак не относится к межплагинным связям с их контрактами. Внутри себя они так же могут использовать разные версии, потому что являются commonjs модулями.
Доопределений и асинхронности поверх commonjs мы лично хотим больше, а чего хотите вы? ;-)
upd: Посмотри на c9/architect и zxqfox/pym.