将Firebase功能分离为自包含的；“包装”；（不是单独的文件-完全单独的包） 原始问题-见最后的答案

我们已经使用Firebase函数2年多了，已经积累了超过120个HTTP、可调用、触发和调度函数，所有这些函数都是从一个

函数/索引

调用的，并由一个

包管理。json

，可能和你们很多人一样。正如你所想象的，我们有一些旧的依赖关系，我们对更新犹豫不决，因为它有太多的代码需要通过、测试等。所以这让我思考，我想问你们中是否有人做过这件事，或者知道为什么这件事行不通

查看GCP仪表板，每个功能都是独立的服务。但是如果您从那里下载代码，您将得到所有120+函数、节点模块等的完整构建。因此，如果我在我的单个

函数

目录上运行

npm deploy

（如果配额不是问题），看起来

Firebase Tools在我的机器或CI工具上获取我的单个构建

将其复制120多次，然后

将整个构建的一个完整副本推送到每个函数中

这让我思考——考虑到我不能也不想一次构建整个项目并部署所有功能，我是否必须将它们都放在一个

函数

目录中，共享一个

包.json

和依赖项，并从一个

函数/索引

导出

有什么原因我不能，例如：

-函数
-functionSingleA（在节点10上运行）
-lib/index.js
-package.json（stripe8.92和joi）
-src/index.ts
-节点单元
-functionGroupB（在节点12上运行）
-lib/index.js
-package.json（stripe 8.129和@hapi/joi）
-src/index.ts
-节点单元

我知道我失去了一次部署所有资源的能力，但由于配额限制，我再也没有这种奢侈了。除此之外，还有什么理由不起作用吗？毕竟，正如我所知，Firebase函数只是内置Firebase凭据的单个无服务器云函数。是我遗漏了什么，还是你这样做了，它工作正常（或者破坏了一切）

谷歌Firebase团队的回答 Firebase工程师通过支持确认这是绝对可能的，但也可以查看我和@samthecodingman之间的讨论。您可以使用不同的

package.json

文件和依赖项将函数分解为完全独立的模块或组，并在不影响其他函数的情况下部署每个模块或组

---

作为回报，您失去了使用

firebase函数deploy

命令部署所有函数的能力（尽管@samthecodingman提供了一个解决方案），并且您失去了在本地模拟函数的能力。我还没有解决这个问题的方法。

通过将文件结构调整到以下位置，应该可以：

- functionProjects
  - deployAll.sh
  - node10
    - deploy.sh
    - firebase.json
    - functions
      - lib/index.js
      - package.json (stripe 8.92 and joi)
      - src/index.ts
      - node_modules
  - node12
    - deploy.sh
    - firebase.json
    - functions
      - lib/index.js
      - package.json (stripe 8.129 and @hapi/joi)
      - src/index.ts
      - node_modules

作为一个粗略的想法，你应该能够使用一个脚本。使用目标部署命令，它应该保持其他函数不变（即，它不会要求您删除缺少的函数）

每个

deploy.sh

都应该将工作目录更改为它所在的位置，然后执行目标deploy命令

#!/bin/bash 
# update current working directory to where the script resides
SCRIPTPATH=$(readlink -f "$0")
SCRIPTPARENT=$(dirname "$SCRIPTPATH")
pushd $SCRIPTPARENT
firebase deploy --only functions:function1InThisFolder,functions:function2InThisFolder,functions:function3InThisFolder,...
popd

deployAll.sh

文件只执行每个“子”文件夹的

deploy.sh

#!/bin/bash
/bin/bash ./node10/deploy.sh
/bin/bash ./node12/deploy.sh

这需要维护

deploy.sh

中的函数列表，但我认为这不是一个很高的要求。您可以模拟

firebase函数

库，以便调用

函数.https.onRequest（）

（以及其他函数导出）只需返回

true

，并根据需要使用它来获取函数的动态列表

---

您还可以通过添加

“函数”：{{{“源”：“}}来展平文件结构，以便
/node10
和
/node12
是部署的函数目录（而不是嵌套的
函数
文件夹）

到它们各自的

firebase.json

文件。

所以我真正放弃的是立即模拟整个套件。但除此之外，您似乎同意它们实际上是自包含的无服务器函数。不应该把它们从依赖的观点中分离出来吗？我甚至没有想到你不能同时模仿它们。无论如何，您都不能同时模拟node10和node12的功能。我经常在一个项目中同时运行“不同的构建”，您只需要能够识别当前部署的构建，特别是如果您有共享代码的函数。关于您所说的复制120多次的部分，这是执行验证检查的CLI，以确保在部署之前可以正确引导每个函数。最后一部分是上载整个函数目录，并将函数链接到公共代码部署。如果使用目标部署，所选功能将切换到新版本，但未触及的功能仍将连接到旧版本。重新“复制120次”-我明白你的意思，但我的意思是，整个软件包都上传到每个函数中，因此似乎每个函数都可以单独构建，并且有自己的依赖项，只要它是单独部署的。我认为，只要我了解我可能放弃的东西（即，模拟完整套件，一次部署所有组件），这是可能的。我还获得了Firebase支持的入场券。如果我在接下来的24小时内得到正式答复，我会发布它。如果没有，我就接受。谢谢