Имеется условный js-конфигурационный файл, который экспортируется в виде объекта со свойствами.
Некоторые из свойств могут быть установлены по "ленивому" методу, то есть не сразу, а в процессе инициализации, но экспорт всех превентивный.
Пример абстрактного configs.js:
let someLazy = null;
module.exports = { someLazy, someOther: true };
Чтобы повысить читабельную способность, в том числе, уменьшая строки кода, обычно используется деструктурированный импорт. В обычном commonjs поведение деструктуризации таковое, что создаётся локальная переменная без всякой привязки к свойству исходного объекта. Однако же в стандартах import/export
результат отличается и эту концепцию называют
"live bindings" .
Предположительный setLazy.js:
const configs = require("./configs");
setTimeout(() => {
configs.someLazy = true;
}, 1000);
Основной допустимый модуль main.js:
//Подключение логики setLazy
require("./setLazy");
//Деструктурированный импорт
const { someLazy } = require("./configs");
//Стандартный импорт
const configs = require("./configs");
setTimeout(() => {
//Значение здесь будет изменено на true
console.log(configs.someLazy);
//А тут останется null, что и надобно изменить, приводя к поведению import/export esm, оставив при этом читабельный импорт commonjs'а
console.log(someLazy);
}, 1001);
Конечно можно использовать обычную импортную составляющую, но это приведёт к потере удобств, а также, если свойства будут слишком длинными, то таковая потеря случится не только вдвойне, но и способна затронуть производительность в ситуации, когда инициализировано большое количество объектов(интерпретатор лично не сокращает длинные названия, скорее всего из-за развитой рефлексии языка).
Подытоживая, собственно, есть ли какие-нибудь ухищрения, чтобы заставить работать только вышеописанную часть для импортов в commonjs'е по исключительно концепции live-bindings из es-modules?
Или, возможно ли как-нибудь настроить webpack, дабы он обращался исключительно, исходя из вышеперечисленных примеров, к свойству по исходному конфигурационному объекту -
configs.someLazy
, сохраняя на сборочной стороне деструктуризацию?
P.S. Сами конструкции import/export esm не рассматриваются в качестве альтернативы никак, поскольку имеют существенные недостатки для моего контекста: невозможность переопределить import, так как require через Module.wrap; рефлексия исключительно для динамической составляющей; дефолтные принципы экспорта, в перспективе уменьшающие производительность.