Search code examples
firebasegoogle-cloud-functionsfirebase-tools

How to reflect firebase functions console changes to local?

I don't know if it's just not intuitive or just me who have started to learn from bad materials but I'm having a hard time wrapping my head around this logic.

I've written some Firebase functions from my local machine and then deployed the functions. I can see the functions are installed from the Firebase console. Great.

Just for a test I removed one function from the console and headed back to my local development directory. I've tried using firebase CLI to reflect the remote changes any way possible. Either I can't find or there is actually no way to do that?

Just to remove any ambiguity, the question is in the title. But If I was trying to answer the question myself I'd assume Firebase functions are installed local->remote only, and any changes made from the console or extensions installed can't just be pulled to the local.
Does that mean we have to make sure local development files always reflect one and only cloud functions state representing our application logic. In other words do we have to manually delete cloud functions that are no longer defined inside the local files, and make sure not to delete cloud functions that are still present inside the local files?

Thanks a lot for any further guidance.

Solution

  • do we have to manually delete cloud functions that are no longer defined inside the local files, and make sure not to delete cloud functions that are still present inside the local files?

    Yes, if you choose to do things like manually delete functions you've already deployed. But you don't have to do that - you choose to do that, and accept the consequences.

    If you want to delete a deployed function using the Firebase CLI, the more "pure" way to do that is to first remove it from your code, then deploy the code as you normally would. The CLI will detect that you've deleted the function locally, and then remove it from the remote deployment.

    The CLI won't synchronize in the other direction - there is no "reverse deployment" that makes your code match what's in production. It only goes the other direction, from local to remote.