У меня есть приложение, которое использует основной каталог, и помимо основного, у меня есть различные каталоги, которые содержат классы, которые расширяют основные классы и имеют слегка измененную логику c.
Я получил дерево файлов, как показано ниже.
app
|-- core
| |-- x
| |-- y
| |-- z
| `-- plugins
| |-- xyz-helper.js
|
|-- slightly-modified-logic
| `-- plugins
| |-- xyz-helper.js
Я хочу использовать существующие функциональные возможности Webpack для достижения чего-то похожего на «тематическое» решение. У вас есть подтема, где вы можете переопределить шаблоны родительской темы, если вы не переопределите указанный шаблон c, он будет использовать родительскую тему.
Итак, в моем случае идеальным сценарием будет:
1) Смонтировать каталог slightly-modified-logic
2) Зависимости в базовых классах следует разрешать с использованием смонтированного каталога, если смонтированный каталог не обеспечивает собственную реализацию, только тогда откат самим базовым классам.
Я проверил NormalModuleReplacementPlugin
, но это кажется полезным, только если вы хотите повлиять на всю сборку, я хочу, чтобы пакет включал все, этот или блок модуля для каждого неосновного каталога, который я загружаю по требованию.
Я думаю об этом, создав карту resolve
, предполагая, что я могу связать пользовательские псевдонимы пути, и Webpack пробует все из них, прежде чем вернуться к нормальному разрешению. Но как мне сделать это во время выполнения? Решение о монтировании каталога, отличного от основного, должно приниматься на основе параметров времени выполнения.
Мне нужны только некоторые подсказки, спасибо.