在通用/同构应用程序中组织package.json依赖项

Question

使用React和其他框架，现在通常使用npm和package.json来安装您在前端使用的库。如果您正在开发通用/同构应用程序，这会引入前端和后端的依赖项存储在同一文件中的问题，从而创建一个大规模的依赖项列表。

如果你使用npm --save / - save-dev两种类型的依赖项（前端，后端）变得混杂而且很难知道，而不是一个接一个地使用哪一个。< / p>

除了手动排序和管理依赖关系列表之外，还有什么方法可以使列表保持整洁？您管理依赖关系列表的策略是什么？

Answer 1

在通用/同构应用程序中，您可能只有很少的依赖，纯粹是前端或纯后端;大多数依赖项都是共享的。

我想到的一个选项是使用多个package.json：

• 一个用于同构依赖（react，redux等）和实用程序依赖，如构建系统（babel，webpack等），任务运行器（gulp，cross-env），测试（karma）等; < / LI>
• 一个用于纯前端依赖;
• 一个用于纯后端依赖项。

我自己没有使用过这个结构，而且我不确定单个package.json会更难维护，因为你需要管理更多的东西（如果添加npm-shrinkwrap）对此，它是文件的两倍。

Answer 2

我非常同意这种愚蠢的回答，并希望进一步扩展它。我确实认为两个不同的package.json文件是唯一的方法。

将您的前端和后端视为两个不同的应用程序。在两个非常不同的环境中，因此您的包装和构建链需求也会不同。

npm的重点是每个包具有独立的依赖关系。您通过与两个完全不相关的应用程序（前端和后端）共享您的依赖关系列表来反对这一点。

想象一下，招聘新的前端开发人员并且他们想要升级一些前端软件包，现在他们必须继续前进并弄清楚如何运行和/或测试后端，因为它们可能会破坏那些。

在开始时管理两个package.json文件可能会感觉有点麻烦，但这种类型的隔离会让你的应用程序保持健康。

因此我建议你有一个结构，你有两个兄弟文件夹，每个文件夹都有自己的package.json。究竟你想要如何构建由你决定的。

如果你想要在前端和后端之间共享核心业务逻辑，那么当然你可以把它放在一个单独的npm包中，然后你可以在你的后端和前端包中引用它作为依赖。 您可以使用npm link在前端和后端同时针对相同版本进行开发，以提高开发效率。