使用 Yarn Workspaces 在 monorepo 中可重复构建 Lambda 层答案

【问题标题】：Repeatable build for Lambda Layers in monorepo with Yarn Workspaces使用 Yarn Workspaces 在 monorepo 中可重复构建 Lambda 层
【发布时间】：2020-08-18 14:23:02
【问题描述】：

我有相当大的 monorepo，完全由 Yarn Workspaces 管理（没有 Lerna）。其中一个包（“工作区”）包含一组第 3 方 NodeJS 包，我们将其用作 Lambda 函数的shared layer，在此包的package.json 中收集为dependencies。该包的构建脚本应该将所有依赖项收集在一个 zip 文件中，该文件稍后将由 Terraform 发布。不幸的是，Yarn 无法从 monorepo 构建 single 工作空间，因此我们必须直接使用 NPM。

目前我们大致做了以下-

将package.json 复制到build 文件夹
在此文件夹中运行npm install --production
压缩生成的node_modules 树

我对这种方法的主要问题（除了混合构建工具）是构建不可重复 - 每次我们运行 npm install 时，我们可能会获得任何依赖包的更新兼容版本，因为该版本被“锁定”顶级 yarn.lock 文件中的纱线和 NPM（显然）不知道它。

我很确定我们并不孤单。有没有更好的方法可用？

【问题讨论】：

或者您可以保留提升功能并使用 webpack 构建您的功能，我不明白您为什么要压缩 node_modules？
@ZEE 使用 webpack，你会得到一大块难以阅读的 JS 代码。保存代码和代码结构以便能够登录到 Lambda 控制台并添加日志语句非常方便，因为您的代码在实际部署中的行为与单元测试中的行为不同。
源地图就是为此而存在的。
我认为 AWS Lambda 控制台中的代码编辑器不支持源映射 - 除非它最近发生了变化。

标签： node.js npm aws-lambda yarn-workspaces aws-lambda-layers

【解决方案1】：

看起来，虽然 Yarn 提升所有依赖项到顶级工作区的 node_modules，但 you can explicitly opt-out from this behavior 的一些依赖项 - 或者，在我的情况下，对于 all 给定工作区的依赖关系。

之前的 Yarn Workspaces 配置：

"workspaces": [
  "packages/*"
]

更改后的 Yarn Workspaces 配置，假设 Lambda 层依赖项收集在 common-lambda 工作区下：

"workspaces": {
  "packages": [
    "packages/*"
  ],
  "nohoist": [
    "common-lambda/**"
  ]
}

在此更改之后，packages/common-lambda/node_modules 将包含要打包为 Lambda 层的所有依赖项的正确版本。

注意nohoist 数组应包含工作区名称（包括适用的命名空间）而不是工作区文件夹。

【讨论】：