Доступ к кастомным опциям модуля из плагина

[lomadurov]

Есть ли возможность использовать кастомные опции модуля для плагинов?

"modules": {
        "moduleName": {
            "path": "modulePath",
            "some_plugin_option": false
        }
}

На текущий момент насколько я понял опции передаются только те, что были объявленные в lmd_common.js

[lomadurov]

Я это видел, просто данная опция передаётся в options, а возможности изменять данную опцию на уровне модуля нет, т.е. из примера выше я не могу сделать следующее.

"modules": {
        "moduleName": {
            "path": "modulePath",
            "pewpew": false
        }
}

Опция pewpew декларированная для модуля просто не попадёт в modules_options при билдинге. LMD: 1.10.11

[azproduction]

Кастомных опций для модулей нет. Предполагалось, что опции нужны только для внутренностей LMD. Пользователь как и его плагины же должны работать только с модулями. Все "левые" значения у модулей будут игнорированы.

Однако же опции можно определить у юзер-плагина.

"plugins": {
    "pewpew": {
        "options": {
            "module_name": "123"
        }
    }
}

эти опции можно хранить где-нибудь во вне и "прицеплять" к конфигу через .lmd.js

[azproduction]

Расскажи какую задачу ты хочешь решить, используя опции модуля?

[lomadurov]

Пример высосан из пальца Сделал маленький helper plugin для получения списка объявленных модулей. Все модули можно разделить на три типа vendors, core, asserts.

Примерный список модулей:

{
    // Vendors
    "$": "@$",
    "_": "@_",
    "Backbone": "@Backbone",

    // Core
    "core": "modules/core/index.js",
    "core.log": "modules/core/log.js",

    // Util
    "util": "modules/util/index.js",
    "util.log": "modules/util/log.js"

   //...
}

Хочу исключить vendors из списка декларированных модулей не прибегая к созданию списка исключений в скриптах, т.е. использовать config по полной. Отсюда и появилась желание добавить опцию при объявлении сторонних библиотек, которая будет чётко оговаривать, что она является vendor.

[lomadurov]

Думаю, объявления опций в плагине относящихся к модулям, усложнит связанность и возможно создаст избыточность. Для того чтобы избавиться от засорения тонными непонятных значений в описании модуля, можно на уровне Code Guide подсказать пользователям о наименовании опций относящихся к пользовательским дополнениям по определённому правилу, например

"modules": {
        "moduleName": {
            // ...
            "user_plugin": {"some": "options"}
            // ...
        }
}

И на уровне warn в результате сборки предупредить, что таки не рекомендуется использовать не регламентированные опции в описании модуля.

[azproduction]

Я думаю, что области видимости, права доступа и прочие "классовые разграничения модулей" должны определяться на уровне приложения, а не модульной системы. Те еще какой-то оберткой. Это слишком частный случай, чтобы его обобщать в модульной системе.