Suggestion
When creating firebase functions using TypeScript it's possible to structure small projects like this:
// functions/src/index.ts
import {onRequest} from "firebase-functions/https";
export const foo = onRequest((_, response) => {
response.send({ message: 'foo' });
});
export const bar = onRequest((_, response) => {
response.send({ message: 'bar' });
});
However, as the project grows it becomes (in my humble opinion) more advantageous to define functions in separate files and import them into the main file:
// functions/src/index.ts
import {onRequest} from "firebase-functions/https";
import {fooHandler} from "./foo";
import {barHandler} from "./bar";
export const foo = onRequest(fooHandler);
export const bar = onRequest(barHandler);
The main advantages of this approach are:
- Handlers then become easier to test
- Project is much more organized at scale
Those of us who adopt this approach using TypeScript then often encounter the problem "How do we provide accurate types for the handler functions that we are creating in separate files so that they work seamlessly when passed to onRequest, onCall, etc. in the main file?
From a developer perspective it would be ideal if we could import the handler types directly from firebase, which would enable us to simply do something like this:
// functions/src/foo.ts
import {OnRequestHandler} from "firebase-functions/https";
export const fooHandler: OnRequestHandler = (_, response) => {
response.send({ message: 'foo' });
};
One might be inclined to think it's easy for developers to define their own handler types instead of relying on handler types exported by firebase. However, for my personal project I used an AI tool to generate the handler types and it came up with the following:
export type OnRequestHandler = Parameters<typeof onRequest>[0];
export type OnCallHandler<T = unknown, R = void> = (request: CallableRequest<T>) => Promise<R>;
export type OnDocumentCreatedHandler = Parameters<typeof onDocumentCreated>[1];
export type BeforeUserCreatedHandler = Parameters<typeof beforeUserCreated>[0];
export type ScheduleHandler = Parameters<typeof onSchedule>[1];
These are nontrivial, and don't even represent the complete types for all handlers made available by firebase. I am interested to hear your thoughts, and the thoughts of others, on the possibility of firebase-functions beginning to export the handler types.
Related issues
N/A
[REQUIRED] Version info
node: v24.14.1
firebase-functions: 7.2.5
firebase-tools: N/A
firebase-admin: N/A
[REQUIRED] Test case
N/A
[REQUIRED] Steps to reproduce
N/A
[REQUIRED] Expected behavior
N/A
[REQUIRED] Actual behavior
N/A
Were you able to successfully deploy your functions?
N/A
Suggestion
When creating firebase functions using TypeScript it's possible to structure small projects like this:
However, as the project grows it becomes (in my humble opinion) more advantageous to define functions in separate files and import them into the main file:
The main advantages of this approach are:
Those of us who adopt this approach using TypeScript then often encounter the problem "How do we provide accurate types for the handler functions that we are creating in separate files so that they work seamlessly when passed to
onRequest,onCall, etc. in the main file?From a developer perspective it would be ideal if we could import the handler types directly from firebase, which would enable us to simply do something like this:
One might be inclined to think it's easy for developers to define their own handler types instead of relying on handler types exported by firebase. However, for my personal project I used an AI tool to generate the handler types and it came up with the following:
These are nontrivial, and don't even represent the complete types for all handlers made available by firebase. I am interested to hear your thoughts, and the thoughts of others, on the possibility of firebase-functions beginning to export the handler types.
Related issues
N/A
[REQUIRED] Version info
node: v24.14.1
firebase-functions: 7.2.5
firebase-tools: N/A
firebase-admin: N/A
[REQUIRED] Test case
N/A
[REQUIRED] Steps to reproduce
N/A
[REQUIRED] Expected behavior
N/A
[REQUIRED] Actual behavior
N/A
Were you able to successfully deploy your functions?
N/A