node.js - 使用依赖关系构建monorepo babel编译的 Node JS应用程序

我正在做一个作为monorepo托管的项目。为了简化起见，假设内部有三个不言自明的程序包：server，webapp客户端和library。目录结构如下所示：

the-project
  packages
    server
      src
    webapp
      src
    library
      src

所有软件包都使用流类型表示法，使用一些> ES5功能，因此，需要进行babel转译。关键区别在于webapp包的转译是通过webpack完成的，而server则采用了一项gulp任务，该任务触发了通过gulp-babel包的脚本转译。构建library时会自动转译web。

现在，我的问题是要构建server，babel要求先构建library，然后其package.json指定其（已构建）主JS源文件，以便可以包含其转译的工件。可以想象，如果项目包含多个正在积极开发的库（确实如此），这将很快成为问题，因为所有库都需要构建，包括任何依赖包（在这种简单情况下，例如server）。

为了克服这种烦恼，我最初想到了使用webpack来构建服务器，它将负责将其所需的任何依赖项都包含在捆绑中，但是我遇到了一些问题，因为显然webpack不打算在节点JS上使用应用程序。

有哪些策略可用于构建需要Babel转译的节点JS应用程序，从而透明地构建该应用程序的源文件以及任何依赖项并将其包含在单个输出目录中？



附件A

server所使用的简化的gulp任务，用于脚本的转译。

return gulp
  .src([`src/**/*.js`], { allowEmpty: true })
  .pipe(babel({ sourceMap: true }))
  .pipe(gulp.dest('dist'));

如上所示，任务中仅包含server自己的源文件。如果将src更改为也包含library，则该任务将在server自己的输出目录中发出依赖项的工件，并且其中的任何require('library')语句都将尝试在packages/library中定位已构建的工件。而不是packages/server/dist，从而导致导入失败。

最佳答案

首先，我不确定您的服务器在做什么。如果它正在进行数据库连接或进行某些计算，则我不建议由webpack构建它。而如果您的服务器只是在进行服务器端渲染并向其他服务器进行一些API调用，那么我建议使用webpack将其捆绑在一起。

许多项目都遵循这种理念。例如，您可以看一下我在一个个人项目 [Blubus]中所做的类似事情。具体来说，您可能对webpack-server-config感兴趣。您也可以看看spectrum这样的大型项目是如何完成的。

关于node.js - 使用依赖关系构建monorepo babel编译的 Node JS应用程序，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/52465627/