Commerce Cloud 中的构建过程在我的项目存储库中查找我的项目自定义 customization. 有两种反对的自定义目录构造。
Separate subdirectories for each customization
这是默认并且举荐的抉择。
每个自定义应用独自的子目录。如下图所示：
在此配置中，构建器心愿找到一个 core-customize 子目录和几个可选目录。
- core-customize（必须）- 蕴含 SAP Commerce Cloud 和清单文件的自定义。
- js-storefront（可选）- 蕴含 Javascript 店面自定义和清单文件。
- datahub（可选）- 蕴含 Data Hub 自定义和清单文件。
每个 Customization 必须蕴含一个 manifest.json 文件。
Single directory for all customizations
这种做法曾经 deprecated 了。应用单个根目录是配置存储库的原始形式。此配置仍受反对，但不举荐应用且已弃用。在这种构造里，所有目录都间接增加到根目录中。不反对 JavaScript 店面。
Builder 在运行时怎么晓得客户采取的哪一种 Customization 形式呢？
构建过程在根目录中查找 Commerce Cloud manifest.json 文件。如果它找到清单文件，则应用 deprecated 即所有 Customization 位于同一文件夹内的层级构造。如果它没有找到清单文件，则阐明每个 Customization 具备各自的子文件夹。
当您应用独自的子目录构造时，Javascript 应用程序门路绝对于 <root>/js-storefront.
看个例子：
这里的 Spartacusstore, 是 js-storefront 上面的一个子文件夹。
在 manifest.json 里不要应用绝对路径 / 结尾。
门路被认为是 *nix 格局，因而应用斜杠分隔目录。
如果之前从原始的单个目录构造开始，您能够进行一些小的更改以迁徙到举荐的独自子目录构造。
这些语法在 manifest.json 文件中不被反对：
- 在目录树中向上（’..’）
- 解析当前目录（’.’）
- 从机器根目录（’/’）开始
- Shell 扩大，例如（‘*’ 或 ‘~’）
- 环境变量扩大，例如（‘$HOME’ 或 ‘${HOME}’）