模块化跨项目设计/创建可重复使用的可扩展基础

Question

上下文

我们正在创建一个由多个应用门户组成的新解决方案（缺少一个更好的术语），每个门户网站都需要利用已经包含一些我所使用的专有代码的基础项目。作为与该门户网站相关的任何新功能。我们当前的应用程序还有很多不足之处，而且随着我们重新开始，我们希望以正确的方式实现它。 （因此，我想稍微考虑一下我的想法）

我想过几种可能的方法来解决这个问题。每个人都有它的职业＆＃39;和缺点。

1。 GIT Fork A基础项目：

这似乎是最直接的方式。拥有PortalCore 项目，然后让每个项目以下游方式分叉。

• Con：如果基数发生变化，我们需要手动更新所有相关项目。
• 专业版：最初更容易实施，我相信会减少其他更多＆＃34;费力的＆＃34;任务。 （示例，单个构建文件将随每个新门户一起使用我们的构建要求。）

流程将是：

  

Fork PortalCore＆gt;核心将通过GIT master

更新来保持最新

2。基础项目NPM包：

这似乎是一个理想的路线，因为每个部署都会在每个门户网站上安装最新版本的基础软件包/项目。

• Con：从我的研究看来，我们似乎无法在npm文件夹之外安装npm软件包（这与我的问题有关）。如果我们希望它位于项目根目录中，我们需要通过其他方式共享构建文件。
• Pro：使用构建过程自动推出更新

流程将是：

  

新项目＆gt;添加Portal Core npm＆gt;制作自定义构建任务，或抓取   来自某些中央回购＆gt;将通过npm install＆gt;保持最新   Gulp Build

第3。结合以上

让git项目只包含我们的基本npm模块，＆amp;构建配置。然后构建可以处理诸如将文件移动到正确位置之类的事情（例如.node_modles - ＆gt; root）

流程将是：

  

Fork PortalCore＆gt; Core将通过npm install＆gt;保持最新状态Gulp Build

<小时/> 的的问题：

1. 有没有办法让npm包（或其他包管理器）将文件安装到特定位置？ （我查看了npm论坛，这似乎是一个死胡同。但我想我在这里试试运气。）
2. 我们是坦率地说吗？我们不想创造一个新的怪物。这种逻辑是否有意义ITO创造的东西应该在某种程度上通过设计模块化，但允许更容易的维护。大男孩如何做到这一点...如果他们这样做？

Answer 1

对此的答案最终比我预期的要简单得多：

• 将所有共享服务放在单独的公共NPM包中（通用组件，共享/公共服务等）

• 并创建一些辅助初始项目的自动生成器 初始化。 （唯一的缺点是有人需要维护它们， 应该有一些新的核心依赖性......但这就是开发生活。）