依赖对Firebase Functions冷启动的影响及相关技术咨询

背景与简化场景 #

• 拥有约20个Firebase Cloud Functions，统一存储在reporoot/functions/src/目录下，所有依赖声明在同一个reporoot/functions/package.json中
• 简化场景：
  1. package.json的dependencies包含LibA、LibB，devDependencies包含LibX
  2. reporoot/functions/src/myFeatureSet1/feature1.ts通过import functionA from LibA定义CloudFunction1
  3. reporoot/functions/src/myFeatureSet2/feature2.ts通过import functionB from LibB定义CloudFunction2

技术问题解答 #

问题1：部署CloudFunction1到Firebase时，部署压缩包会包含LibA、LibB和LibX，还是仅包含CloudFunction1引用的LibA？ #

默认情况下，Firebase CLI会打包functions目录下所有dependencies声明的依赖，也就是LibA和LibB都会被包含；但devDependencies中的LibX不会被包含，因为部署阶段默认执行npm i --production，只会安装生产依赖。所以最终部署包包含LibA和LibB，不包含LibX，并非仅包含LibA。

问题2：依赖数量会影响同一package.json下所有函数的冷启动时间吗？还是部署后的函数仅包含所需依赖？ #

会影响。在单package.json的结构下，所有函数共享同一个node_modules环境，部署后每个函数启动时都会加载整个dependencies中的所有依赖，不管该函数是否实际用到。依赖数量越多，冷启动时需要加载和解析的代码量越大，启动速度越慢。

问题3：devDependencies的数量会影响同一package.json下所有函数的冷启动时间吗？我认为部署时会执行npm i --production，不会包含devDependencies，该观点是否正确？ #

你的观点正确。部署时Firebase CLI默认执行npm i --production，devDependencies不会被安装到部署环境中，因此不会占用部署包体积，也不会影响函数的冷启动时间。

问题4：若问题2/3的答案为是，如何拆分不同函数的依赖，使每个函数仅打包所需依赖？我参考了Firebase官方文档的多代码库package.json方案，但使用模拟器时出现错误：functions: Failed to load function definition from source: FirebaseError: Error parsing triggers: Cannot find module 'axios'（注：我的一个CloudFunction使用了axios，已在对应package.json中声明）。 #

采用多package.json方案拆分依赖的正确步骤及报错解决方法：

1. 为每个独立功能目录（如myFeatureSet1、myFeatureSet2）单独创建package.json，仅声明该目录下函数所需的依赖（比如CloudFunction1的目录只声明LibA）
2. 移除根functions/package.json中这些拆分出去的依赖
3. 分别进入每个子功能目录，执行npm install安装对应依赖
4. 部署时指定对应子目录作为源码路径，比如：firebase deploy --only functions:CloudFunction1 --source functions/src/myFeatureSet1
5. 模拟器报错的原因通常是未正确加载子目录的node_modules，解决方法：
   • 确保每个子目录都已执行npm install生成本地node_modules
   • 启动模拟器时指定对应子目录的源码，或者在模拟器配置中明确指向函数所在的子目录
   • 检查函数代码中的依赖引用路径，避免跨目录引用未安装的依赖

问题5：使用import functionA from LibA和import * from LibA两种导入方式，代码启动时间是否有差异？ #

有差异。

• import functionA from LibA属于按需导入（若目标库支持tree-shaking），只会加载与functionA相关的代码片段，启动时解析的代码量更少
• import * from LibA会加载整个库的所有导出内容，启动时需要解析更多代码，会增加冷启动时间
  如果库不支持tree-shaking，差异可能较小，但仍推荐使用按需导入来优化启动速度。

内容的提问来源于stack exchange，提问作者Cupid Chan