我们最近已将现有的基于PHP的视图迁移到多个基于React的“功能”位于
/react目录中，并组织到/react/featureName子目录中。这意味着Laravel的控制器主要只处理数据和身份验证。每个功能都由一个或多个开发人员维护，具有自己的依赖性，测试和功能。
我们目前正在按功能组织我们项目的公共根目录中的构建：
js/FeatureName.hashed.js
css/FeatureName.hased.css
效果很好，但我们共享许多介于
features之间的软件包。 React本身，react-router等。我们打算尽可能多地使用Laravel的
mix.js，但是直接对webpack.config进行黑客攻击也是一种选择。 我已经研究了
mix.extract()选项，该选项使我们可以定义vendor.js与其他应用程序逻辑分开的构建，但它在那里停止。 有什么方法可以管理每个功能目录中存在的多个
package.json文件我们如何识别通用软件包并将其锁定在根
/package.json文件中。 （独立地，所有开发人员都已经使用yarn）如何为所有基于反应的开发人员以尽可能少的摩擦来完成此任务-这样他们就可以继续他们已经做的一切，而DevOps可以处理那些棘手的问题？ br />
我了解可能需要更多信息，请在评论中大喊您的需求，我很乐意更新问题。
#1 楼
有什么方法可以管理每个功能目录中的多个package.json文件？
每个人都可以将package.json保留在每个功能目录中功能目录，并在构建应用程序时让CI读取package.json。可以在package.json中定义依赖项的版本，以获得对应用程序的控制。如果该应用程序使用某个库的ABC版本，则可以定义该版本以防止更新会破坏该应用程序。
我们如何识别常见的软件包和将它们锁定到根/package.json文件中。 （独立地，所有开发人员都已经使用yarn了）。
与团队讨论此问题，并找出对每个人来说最佳的解决方案。多种解决方案是可能的。每个人都应该对某种方法感到满意。
如何为所有基于反应的开发人员以尽可能少的摩擦来完成此任务-这样他们就可以简单地继续
无论他们已经在做什么，DevOps都会处理这些棘手的问题？
DevOps在我看来意味着一个由多个专业组成的团队，例如测试，开发，运营负责某个应用。这意味着整个团队应该同意某种方法，并且每个人都应该按照该过程来工作和处理问题，而不是要讨论有关筒仓的
DevOps handles the gritty bits，然后“扔掉它”
评论
我建议在这篇文章中保留最重要的问题，并在单独的文章中询问其他问题，最终参考这篇文章以免重复细节。我还建议删除问题中的“最佳方法”-它使问题基于观点，这是令人讨厌的。用“ How”代替它怎么样？如果您可能得到多个答案，则投票数将表明哪个是最受欢迎的，通过接受其中一个来表明最适合您。