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

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

如果你使用npm –save / save-dev这两种types的依赖关系(前端,后端)变得混杂,很难知道,而不是一个接一个,哪一个在哪里使用。

除了手动sorting和pipe理依赖列表之外,有没有办法保持列表整洁? 你有什么策略来pipe理依赖列表?

       

网上收集的解决方案 "在通用/同构应用程序中组织package.json依赖项"

在一个通用/同构的应用程序中,可能只有很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在您的前端和后端同时开发相同的版本,以提高开发的舒适度。