使用依赖项构建monorepo babel编译的节点JS应用程序

Question

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

the-project 
  packages
    server
      src
    webapp
      src
    library
      src

所有软件包都使用流类型符号，使用一些> ES5功能，因此，需要进行babel转换。关键区别在于webapp包的转译是通过webpack进行的，而server采用的是吞噬任务，该任务通过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中定位构建的工件，从而导致导入失败。

Answer 1

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

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