fix: ignore cached project during firebase init (#9509)

[eloiberlinger1]

Description

This PR fixes #9509 by ensuring that firebase init ignores the cached project ID stored in the global configstore.

Reasoning

Currently, if a directory was previously associated with a project and then deleted/recreated, the CLI automatically picks up the old project ID. This causes confusion and 403 errors if the project is no longer accessible. By ignoring the cache during init, we force the CLI to prompt the user for project selection, which is the expected behavior for a new initialization.

Scenarios Tested

1. Create a directory and init a project.
2. Delete the directory and its contents.
3. Recreate the directory and run firebase init.
4. The CLI should now prompt for project selection instead of using the old ID.

Sample Commands

mkdir project
cd project
firebase init hosting

Verify that the project selection prompt appears even if

this directory path was previously used.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Summary of Changes

Hello @eloiberlinger1, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves an issue where the firebase init command would inadvertently reuse a previously cached project ID, causing unexpected errors and an inconsistent user experience. By preventing the init command from utilizing the global configstore's cached project ID, the CLI will now consistently prompt users for project selection, ensuring a clean and explicit setup process for new Firebase projects.

Highlights

• Fixes firebase init behavior: Addresses an issue where firebase init would automatically use a cached project ID from the global configstore, leading to potential 403 errors if the project was no longer accessible.
• Ensures project selection prompt: Modifies the applyRC method to explicitly ignore cached project IDs when the init command is run, forcing the CLI to prompt the user for project selection, which is the expected behavior for a new initialization.
• Improved user experience: Prevents confusion and errors by ensuring that users are always prompted to select a project when initializing a new Firebase project, even if the directory path was previously associated with another project.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This PR fixes an issue where firebase init would incorrectly use a cached project ID. The change correctly prevents loading the cached project for the init command. My review includes a suggestion to make the detection of the init command more robust and to address a potential type-safety issue in the modified code block.

[gemini-code-assist]

This implementation has a couple of issues:

1. Using process.argv.includes("init") to detect the init command is fragile. It can lead to false positives if another command or an argument contains the substring "init" (e.g., a project ID like my-init-project). A more robust approach is to check the command name directly using this.name === 'init'.
2. There's a potential type mismatch. activeProject is of type string | null, but it's passed to reconcileStudioFirebaseProject, which expects string | undefined. This can cause type errors.

I suggest refactoring this block to address both points for improved robustness and type safety.

    let activeProject: string | undefined;
    if (this.name !== "init") {
      activeProject = this.configstoreProject(options.projectRoot || process.cwd()) ?? undefined;
    }