await analytics.track() produces TS80007 because Analytics interface returns void instead of Promise<void>

[muhammedaksam]

Describe the bug

Using await analytics.track(...) (and page, identify, setEnabled) produces TS80007: 'await' has no effect on the type of this expression.
The Analytics interface in @wxt-dev/analytics declares all methods as returning void, even though the background implementation is async (returns Promise<void>). The frontend implementation returns void. Since Promise<void> is assignable to void, there's no implementation error — but users calling await analytics.track() see TS80007 because the declared return type is void.

Reproduction

1. Create a WXT project with @wxt-dev/analytics configured
2. In any entrypoint (popup, options, content script, etc.), call await analytics.track('my_event')
3. Observe TS80007 in the editor or type checker

Steps to reproduce

1. npm create wxt@latest -- wxt-analytics-test
2. cd wxt-analytics-test
3. npm i @wxt-dev/analytics
4. Add analytics config to app.config.ts
5. In an entrypoint: await analytics.track('test')
6. npx tsc --noEmit

System Info

System:
    OS: Linux 7.0 Arch Linux
    CPU: (12) x64 Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz
    Memory: 4.42 GB / 15.55 GB
    Container: Yes
    Shell: 5.9 - /usr/bin/zsh
  Binaries:
    Node: 24.11.1 - /home/xanela/.config/nvm/versions/node/v24.11.1/bin/node
    Yarn: 1.22.22 - /home/xanela/.config/nvm/versions/node/v24.11.1/bin/yarn
    npm: 11.6.2 - /home/xanela/.config/nvm/versions/node/v24.11.1/bin/npm
    pnpm: 10.25.0 - /home/xanela/.config/nvm/versions/node/v24.11.1/bin/pnpm
    bun: 1.3.3 - /home/xanela/.bun/bin/bun
    Deno: 2.8.0 - /usr/bin/deno
  npmPackages:
    @wxt-dev/analytics: ^0.5.4 => 0.5.4 
    wxt: ^0.20.26 => 0.20.26

Used Package Manager

pnpm

Validations

• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[aklinker1]

This is intentional. Why do you need to await them?

In general, analytics APIs make tracking events sync even if it's async internally. They're designed so you don't have to await the actual upload, maybe because it's queued and uploaded later, or there's some other mechanism that guarentees reproting will succeed. In the analytics case, since we message the background, the background handles the upload and you don't need to await it.

[muhammedaksam]

This is intentional. Why do you need to await them?

In general, analytics APIs make tracking events sync even if it's async internally. They're designed so you don't have to await the actual upload, maybe because it's queued and uploaded later, or there's some other mechanism that guarentees reproting will succeed. In the analytics case, since we message the background, the background handles the upload and you don't need to await it.

Mainly because the package's README recommends using await (which currently throws TS80007). Also, in the background script, the implementation actually awaits the provider uploads, so developers might want to await them there to ensure events are sent before the service worker terminates. Doesn't it make sense to either change the examples in the README to not use await, or update the function signatures to return Promise<void>?

[aklinker1]

Mainly because the package's README recommends using await

👀 I guess I'm misremembering... or the readme is out-of-date.

so developers might want to await them there to ensure events are sent before the service worker terminates

I don't believe the service worker will terminate with fetch requests in progress. Any open socket will keep it alive indefinitely.

Doesn't it make sense to either change the examples in the README to not use await, or update the function signatures to return Promise?

Hmm... There are valid reasons to await the other calls, like analytics.identify(...), which sets a value in storage, and has to be async. So making them consistent would be good. Sure, let's update the types to return a promise.

Thanks for the explanation!