feat(functions): support subsequent installs and multi-project configuration for function kits by wandamora · Pull Request #10931 · firebase/firebase-tools

wandamora · 2026-08-12T22:49:22Z

Description

Enhances the functions:kits:install command to support subsequent installations of an already installed Function Kit package in both single-project and multi-project settings:

Subsequent Install Detection:
- Detects whether the specified package is already configured under a kit in firebase.json.
Project Dotenv Detection & Conditional Prompting:
- Inspects all instance configuration directories (configDir) in the kit for existing .env.<project-id> files matching the active project ID or alias.
- If no .env file exists for the active project (and in interactive mode): Prompts the user to choose between:
  - "Add an instance to the existing kit": Prompts for a new instance ID (or generates a unique ID), creates function-kits/<kit>/config-<instanceId>, and updates firebase.json.
  - "Configure an existing instance for this project": Selects the instance (prompting if multiple exist) and outputs the recommended firebase deploy command so the deploy workflow can prompt for parameters and automatically generate .env.<project-id>.
- If a .env file already exists for the active project (or in --non-interactive mode): Automatically skips the choice prompt and directly proceeds with adding a new instance.
Collision & Validation Checks:
- Ensures instance IDs are unique across all kits and do not collide with existing codebase names.

Scenarios Tested

Subsequent install in non-interactive mode: Auto-generates unique instance ID, updates firebase.json, and skips npm install.
Subsequent install in interactive mode (addInstance): Prompts for custom instance name, creates config directory, and updates firebase.json.
Subsequent install when .env.<current-project> already exists: Skips the action prompt and directly enters addInstance.
Subsequent install with addEnv:
- Single instance + active project: Outputs firebase deploy --only functions:<inst> --project <project> without writing empty .env files or modifying firebase.json.
- Single instance without active project: Outputs deploy suggestion with <project-name> placeholder.
- Multiple instances: Prompts to select which instance to configure.
Duplicate instance ID validation: Rejects duplicate instance IDs and codebase name collisions.
Unit test suite in src/commands/functions-kits-install.spec.ts (57 passing tests).

Sample Commands

firebase functions:kits:install --npm_package <package> for subsequent installs to add an instance
firebase functions:kits:install --npm_package <package> --project <unconfigured-project>

wiz-9635d3485b · 2026-08-12T22:49:57Z

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	20 3
Software Management Findings	-

Total	20 3

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try the Wiz Code extension for VS Code, JetBrains, or Visual Studio.

gemini-code-assist

Code Review

This pull request introduces support for subsequent installations of already installed function kits, allowing users to add new instances or configure existing ones for their active project. The review feedback highlights a potential TypeError when options.rc.projects is undefined, recommends throwing a FirebaseError in non-interactive mode if multiple matching kits are found, and suggests simplifying the configuration update logic to avoid duplication and silent failures.

We should assume there is at most one kit containing the package to install.

ajperel · 2026-08-13T22:18:38Z

+
+        expect(writeProjectFileStub).to.not.have.been.called;
+        expect(loggerInfoStub).to.have.been.calledWith(
+          sinon.match(/firebase deploy --only functions:inst-1 --project my-staging-project/),


Is it always including a --project flag?

If the active project is the default such that deploy --only functions:inst-1 would do the right thing and the user didn't include a --project flag on install I kind of lean towards not including it. The users may not be familiar with the flag if they're only ever working in one project.

But if there's a CLI convention to always include it or something I could easily be convicned otherwise.

Since it's a standard CLI flag, I don't think should be confusing or misleading to users. We're just being extra explicit about what to run if they want to configure an instance for a certain project.

I might check with Joe. Standard flag doesn't mean commonly used or seen. In my own usage I setup a default project as I configured things and have almost never used the --project flag.

But this is a minor UX nit since you're right it will work. Easy to adjust later and shouldn't block this PR.

I've used --project quite a bit in my own testing, so I'm not sure what speaks to the most common UX :) Getting Joe's insight isn't a bad idea.

Simplifies the instance assignment logic in `functions:kits:install` by directly updating `existingKit.instances` in place instead of performing a redundant search and defensive error check over `configSrc.functions`. Removes the synthetic unit test that artificially zeroed out config mid-execution to hit the unreachable error branch.

- Adds `hasProjectEnv(dir, projectId, projectAlias)` to `src/functions/env.ts` as a generic helper to check for `.env.<projectId>` and `.env.<projectAlias>` in a directory. - Renames `hasDotenvForProject` in `functions-kits-install.ts` to `isKitConfiguredForProject` and delegates directory checks to `hasProjectEnv`. - Eliminates custom `getProjectIdentifiers` resolution and `readdirSync` directory itøeration, aligning with how the CLI resolves environment files.

ajperel

Some last thoughts I trust you to work through. Thanks for addressing my last feedback.

ajperel · 2026-08-17T18:08:00Z

+
+        expect(writeProjectFileStub).to.not.have.been.called;
+        expect(loggerInfoStub).to.have.been.calledWith(
+          sinon.match(/firebase deploy --only functions:inst-1 --project my-staging-project/),


I might check with Joe. Standard flag doesn't mean commonly used or seen. In my own usage I setup a default project as I configured things and have almost never used the --project flag.

But this is a minor UX nit since you're right it will work. Easy to adjust later and shouldn't block this PR.

ajperel · 2026-08-17T18:16:30Z

+): Promise<boolean> {
+  const isThirdParty = isThirdPartyPackage(packageName);
+  if (isThirdParty) {
+    logger.warn(


Could be in a different PR if we want to address... but trying actual installs I wonder if this should use the log bullets like other messages.

Yeah definitely. I was planning to do a small PR for this after this lands.

ajperel · 2026-08-17T20:06:08Z

+  const absConfigDirPath = options.config.path(configDirPath);
+  await fs.ensureDir(absConfigDirPath);
+
+  existingKit.instances[instanceId] = configDirPath;


Comment from Joe's tools review skill:

Finding: Mutating existingKit.instances in-place modifies the shared options.config.src object in memory. While safe in this CLI context because the command exits immediately, it can lead to side effects in long-running processes (like dev servers) or cause state pollution in unit tests.

Suggested Fix: Clone the configuration before mutating (e.g., using _.cloneDeep(options.config.src)).

I don't think we're relying on the mutated existingKit object after this so it'd be safe to do?

Exactly, we're not relying on this object after this as the CLI exits soon after. Also I'm not too worried about tests since unit tests supply a fresh Config object per test.

…Project non-interactive

feat(functions): add instances on for 2+ installs of the same package

3f1c972

gemini-code-assist Bot reviewed Aug 12, 2026

View reviewed changes

Comment thread src/commands/functions-kits-install.ts Outdated

Comment thread src/commands/functions-kits-install.ts Outdated

Comment thread src/commands/functions-kits-install.ts Outdated

wandamora added 2 commits August 12, 2026 23:10

Remove check for multiple kits

ead67b4

We should assume there is at most one kit containing the package to install.

Simplify constructing instance config

32c965c

wandamora marked this pull request as ready for review August 12, 2026 23:31

Merge branch 'main' into morawand-kits-add-instances

ccb9fc2

wandamora requested a review from ajperel August 12, 2026 23:39

ajperel reviewed Aug 13, 2026

View reviewed changes

Comment thread src/commands/functions-kits-install.spec.ts

ajperel reviewed Aug 13, 2026

View reviewed changes

wandamora added 5 commits August 13, 2026 23:48

Update prompts and logs to match design doc

a8d808d

Simplify functions config validation

01a9074

refactor: split install logic into helper functions

4ba1ad8

ajperel approved these changes Aug 17, 2026

View reviewed changes

wandamora and others added 4 commits August 17, 2026 14:05

Merge branch 'main' into morawand-kits-add-instances

600817d

Explicitly check prompts in multiple instance configuration

997868d

Output log with instance id placeholder for promptExistingInstanceFor…

000ace7

…Project non-interactive

Merge branch 'main' into morawand-kits-add-instances

899c8f8

wandamora enabled auto-merge (squash) August 17, 2026 22:51

Merge branch 'main' into morawand-kits-add-instances

e2c483e

wandamora merged commit 414cc02 into main Aug 18, 2026
75 of 80 checks passed

wandamora deleted the morawand-kits-add-instances branch August 18, 2026 00:54

Uh oh!

Conversation

wandamora commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Scenarios Tested

Sample Commands

Uh oh!

wiz-9635d3485b Bot commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Wiz Scan Summary

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ajperel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

wandamora commented Aug 12, 2026 •

edited

Loading

wiz-9635d3485b Bot commented Aug 12, 2026 •

edited

Loading