BREAKING: Break TS build that uses functions.config()

[taeold]

Type out functions.config() API. Use of functions.config() API should now cause a BUILD error at compile time.

import * as functions from "firebase-functions";
import {onRequest} from "firebase-functions/https";
import * as logger from "firebase-functions/logger";

const cfg = functions.config()

export const helloWorld = onRequest((request, response) => {
  logger.info("Hello logs!", cfg);
  response.send("Hello from Firebase!");
});

$ npm run build

> build
> tsc

src/index.ts:5:23 - error TS2349: This expression is not callable.
  Type 'never' has no call signatures.

5 const cfg = functions.config()
                        ~~~~~~


Found 1 error in src/index.ts:5

[gemini-code-assist]

Summary of Changes

Hello @taeold, 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 introduces a significant breaking change by modifying the TypeScript definition of the functions.config() API. The primary goal is to enforce the deprecation of this API at compile time, preventing its accidental use and directing developers towards the recommended environment parameters module. This ensures that projects using firebase-functions v7 or later will encounter a build error if they have not yet migrated away from functions.config(), thereby promoting adherence to the new configuration management practices.

Highlights

• Breaking Change: The functions.config() API is now explicitly typed as never in TypeScript, causing a compile-time build error if used.
• Compile-Time Enforcement: This change ensures that any usage of the deprecated functions.config() will result in a build error, guiding developers to migrate to environment parameters.
• Runtime Behavior: The runtime behavior remains consistent: calling functions.config() will still throw an error with a clear migration message.

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 pull request introduces a breaking change to make functions.config() cause a TypeScript build error upon use. This is achieved by re-typing config as never, which correctly prevents its usage in TypeScript projects at compile time. The runtime behavior is preserved, where a call to config will throw an informative error, which is beneficial for JavaScript users. The accompanying test changes are also correct, using @ts-expect-error to acknowledge the new compile-time error while still verifying the runtime error. The implementation is clever and effectively achieves the stated goal. The changes look good.

[jhuleatt]

I love this attention to detail to make config deprecation as clear as possible!

[jhuleatt]

What does adding in the as unknown do? I tried removing it in the TS playground and it doesn't seem to change anything

[taeold]

iiuc as unknown basically erases types before and I think I needed to do it to ultimately cast this type as never to prevent tsc from complaining. let me double check to confirm!

[taeold]

Confirmed that this isn't necessary. Great catch!