【问题标题】：How to copy "node_modules" using by "webpack-node-externals" to directory with production building?如何使用“webpack-node-externals”将“node_modules”复制到生产环境中的目录？
【发布时间】：2020-10-13 09:42:06
【问题描述】：

考虑使用 NodeJS 后端的全栈应用程序项目。

package.json 包含 both 前端（如vue、vuex 等）和后端（如body-parser、express 等）的依赖项。李>
前端入口点 (EntryPoint-FrontEnd.js) 和后端入口点 (EntryPoint-BackEnd.js) 由不同的 Webpack 配置构建；主要区别在于后端使用webpack-node-externals 和target: "node"。
前端的依赖项被捆绑到EntryPoint-FrontEnd.js，但EntryPoint-BackEnd.js 使用webpack-node-externals 访问依赖项。

现在：如何仅将那些使用 EntryPoint-BackEnd.js 的依赖项复制到 02-ProductionBuild webpack-node-externals?

我很高兴能通过webpack-node-externals 联系到它，但如果不可能，欢迎使用其他工具。

基本做法是将整个项目部署到通过npm install 托管和安装依赖项。但是，我们在服务器中运行应用程序所需的只是 02-ProductionBuild 文件夹，其中包括 EntryPoint-BackEnd.js 的依赖项。

【问题讨论】：

#1 你能改进你的源代码管理吗？ #2 总而言之，您的挑战是：如何将特定的 npm 库移动到自定义文件夹？
@JRichardsz 感谢您的评论。 “你能改进你的源代码管理吗？” - 我总是能够改进我的源代码管理，但我这样做是基于逻辑和理由，而不是“因为每个人都这样做”。所以，建设性的批评是受欢迎的。 “总而言之，您的挑战是：如何将特定的 npm 库移动到自定义文件夹？” - 确实如此，但问题是库正在使用其他库，因此“特定”不是dependencies 的一部分。
不确定你的问题是什么，但听起来你已经过度设计了一个不需要存在的问题，你为什么要尝试共享 node_modules （我不会，但即使在我当前的工作项目是否不需要任何困难或奇怪的 webpack 模块）？
@Dominic "why are you trying to share node_modules"，因为后端应用程序 (EntryPoint-BackEnd.js) 需要其中的一部分。如果我们尝试将它们捆绑到EntryPoint-BackEnd.js，webpack 将投射警告并且可能应用程序将无法正常工作。如果开始 google 这个警告，“使用webpack-node-externals”将被推荐。

标签： node.js webpack

【解决方案1】：

问题根源

您有多个应用程序的一个存储库
您将前端和后端依赖项集中在一个文件中：package.json

解决方法

创建一个能够为存储库中的每个应用程序创建 package.json 的 npm 模块。虚构名称：packagify
在您的 package.json 中添加脚本以执行单独的构建

    {
      "build:frontend" : "packagify ....",
      "build:backend" : "packagify ...."
    }

如果您不想以优雅的方式创建新的 npm 库，您可以创建一个简单的 packagify.js 文件并从脚本中调用它：

    {
      "build:frontend" : "packagify.js ....",
      "build:backend" : "packagify.js ...."
    }

一些建议

不要将多个应用程序合并到一个源代码存储库中。每个应用都必须有自己的源代码存储库
将当前存储库拆分为两个存储库：一个用于前端，一个用于后端
如果每个应用程序都有自己的源代码存储库，那么构建或部署它们就不会出现问题。这称为：独立部署
如果您的组织发展壮大，您可以避免使用微前端的新单体

单片前端

由于您使用的是vue，因此可以确定您的后端是rest api。因此，您接近与单体应用程序相反的经典方法。

一个单一的特性：

前端和后端源代码在同一个存储库中

但是，如果您将数十个 Web 功能放在同一个 Web 应用程序中会发生什么？一个新的怪物诞生了：

微前端和微服务

非常总结，微前端与微服务相同，但用于前端

您应该已经知道，微服务有很多优势。这些优势也适用于微前端。其中最重要的一项是：独立部署

独立部署

就像微服务一样，微前端的独立部署能力是关键。这会缩小任何给定部署的范围，进而降低相关风险。

在你的情况下，

检查这些链接；

【讨论】：

感谢您的回答。我明白你建议我重新设计我的应用程序，而你是全栈单体的反对者。我看到标准的 Nuxt.JS 项目和 Laravel 项目也是全栈单体。你会宣布所有这些结构都是错误的吗？请注意，这个问题不是攻击性问题，只是试图理解您的意见，因为我无法如此简单地重新构建我的应用程序。
我之所以使用全栈单体，是因为有TypeScript，展台前端和后端现在可以遵守一个业务规则。对我来说，保持全栈单体架构就足够了，因为业务规则具有最大的优先级和对决策的影响。
非常好的 :D 反馈。我们可以使用房间chat.stackoverflow.com/rooms/223361/… 吗？
赏金已经结束，没有直接的解决方案。根据目前的信息，结论将是：“Webpack 没有提出一些工具来解决这个问题，也因为无法在 package.json 中指定哪些依赖项用于前端，哪些依赖项用于后端。达到预期在不改变项目结构的情况下，我们需要创建新工具。”