咱们以一个具体的例子来阐明该原理。

咱们查看某 integration library 目录下的 public_api.ts:

关注 module：

这个 lib 蕴含的 module 为 EpdVisualizationModule 以及对应的配置：EpdVisualizationConfig

留神第八行 import 的 VisualPickingTabModule，这个才是蕴含了 Angular Component 的 module.

入口是 VisualPickingTabComponent：

对于 Spartacus 来说，它只关怀最顶层的 EpdVisualizationModule.

SpartacusFeaturesModule

SpartacusFeaturesModule 旨在轻松治理所有非核心 Spartacus 性能，包含动态加载和提早加载。它充当所有性能的入口点，现实状况下，这些性能被包装到本人的独立功能模块中。

在晚期的 3.x 主要版本中，SpartacusFeaturesModule 可能看起来臃肿而繁忙，但随着每个间断的公布，它应该变得更加简洁，因为致力将大部分性能移到独自的库中。

现实状况下，能够将一个残缺的性能封装到一个特定的功能模块中。该模块能够蕴含与性能相干的配置以及自定义。

依据环境变量 environment 对应的值来决定插入哪些 feature module 到数组 featureModules 里。

最初

SpartacusFeatureModule import 的 module 蕴含两局部，mandatory 的 core module(硬编码)，以及上文形容的 featureModules 数组里的 module 两局部。

linux 零碎：

export SPA_ENV=epd-visualization

windows 零碎：
set CX_EPD_VISUALIZATION=true&& yarn start:local

开启 CX_EPD_VISUALIZATION 之后，就能看到对应的 CMS mapping 了：

更多 Jerry 的原创文章，尽在：” 汪子熙 ”: