Can't pass combination of expected and custom event names to analytics' logEvents()

[JGJP]

• Operating System version: macOS 10.15.7
• Browser version: Brave latest
• Firebase SDK version: 9.6.10
• Firebase Product: analytics

Setup code:

import { initializeApp } from "firebase/app"
import { getAnalytics, logEvent } from "firebase/analytics"

const firebaseApp = initializeApp(firebaseConfig)
const analytics = getAnalytics(firebaseApp)

Working:

type CustomEventNamesOnly = "some_custom_event" | "some_other_custom_event"
logEvent<CustomEventNamesOnly>(analytics, eventName, eventParams)

Also working:

type ExpectedEventNamesOnly = "select_item" | "set_checkout_option"
logEvent(analytics, eventName as ExpectedEventNamesOnly, eventParams)

Not working:

type CustomAndStandardEventNames = "some_custom_event" | "select_item"
logEvent<CustomAndStandardEventNames>(analytics, eventName, eventParams)

In reality I'm using logEvent inside of a function that I'm calling from multiple places in my app, and I want to pass something like CustomAndStandardEventNames to logEvent as the type for eventName.

It currently returns an error because of this type narrowing to never when the event name extends EventNameString but I don't see a good reason for this.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[hsubox76]

If I recall, the reason for it is that otherwise it won't be restrictive when you're using a standard event name, it'll use the same loose typing when given any event name, like if you use "add_payment_info" it'll let you put any parameters because it'll just guess that you're using a custom event name and use that overload. I admit I'm not the best Typescript expert in the world so if anyone can figure a better way around this, which I'm sure there is, feel free to suggest, or even submit a PR.

[JGJP]

This was a long time ago now, but something like this (or equivalent change) should fix the issue IIRC:

export type CustomEventName<T> = T;

I think I did something like this in a patch to resolve it at the time, but I no longer have access to that code.