在通用/同构应用程序中组织package.json依赖项
有了React和其他框架，现在通常使用npm和package.json来安装你将在前端使用的库。 如果您正在开发通用/同构应用程序，则会引入前端和后端的依赖项存储在同一个文件中的问题，从而创build大量的依赖项列表。
如果你使用npm –save / save-dev这两种types的依赖关系（前端，后端）变得混杂，很难知道，而不是一个接一个，哪一个在哪里使用。
除了手动sorting和pipe理依赖列表之外，有没有办法保持列表整洁？ 你有什么策略来pipe理依赖列表？
在一个通用/同构的应用程序中，可能只有很less的依赖关系是纯粹的前端或纯粹的后端; 大部分的依赖是共享的。
我想到的一个select是使用多个package.json ：
- 一个用于构build系统（babel，webpack等），任务运行者（gulp，cross-env），testing（karma）等同构依赖关系（react，redux等）和实用程序依赖关系;
- 一个用于纯粹的前端依赖;
- 一个用于纯粹的后端依赖。
我自己还没有使用过这个结构，我不确定单个package.json是否会更好维护，因为你必须pipe理更多的东西（如果你添加了npm-shrinkwrap，那么它会重复两次作为更多的文件）。
我非常同意sompylasar答案，并希望进一步扩大它。 我真的认为两个不同的package.json文件是唯一的方法来做到这一点。
把你的前端和后端想象成两个不同的应用程序。 在两个非常不同的环境中，您的包装和构build链需求也会不同。
npm的要点是每个包都有独立的依赖关系 。 通过与两个完全不相关的应用程序（前端和后端）共享您的依赖项列表，您将违背这一规定。
想象一下，雇用新的前端开发人员，他们想升级一些前端软件包，现在他们必须继续前进，并弄清楚如何运行和testing后端，因为他们可能会破坏那里的东西。
这可能会觉得在开始时pipe理两个package.json文件会更麻烦一些，但是这种隔离方式会使您的应用程序保持健全的发展。
因此，我会推荐一个结构，你有两个兄弟文件夹，每个他们自己的package.json。 你究竟是如何构build的，取决于你。
如果你想在前端和后端之间共享核心业务逻辑，那么你可以把它放在一个单独的npm包中，然后你可以在后端和前端包中引用它作为依赖。 您可以使用npm link在您的前端和后端同时开发相同的版本，以提高开发的舒适度。