Some types do not reflect the implementation

[Jan Hettenkofer]

Dashlane's initial testing indicates that chrome-types is incomplete. We have put together an example that shows how a valid use of the API fails to compile when chrome-types is used: https://github.com/JanHett/chrome-types-bug-example.

Is this a known issue that will be addressed in upcoming releases?

cc: @tregagnon and @bradcush

[Sam Thorogood]

Thank you for the detailed bug report.

There seems to be two parts of this:

1. missing QueryInfo and TabActiveInfo. Can you tell me where these are referenced? In our internal type system, these are inline types on the callbacks themselves. They don't have a top-level representation, e.g.:

    export const onActivated: chrome.events.Event<
      /**
       * @param activeInfo
       */
      (
        activeInfo: {
          /**
           * The ID of the tab that has become active.
           */
          tabId: number,

          /**
           * The ID of the window the active tab changed inside of.
           */
          windowId: number,
        },
      ) => void
    >;

2. The bigger issue here is the callbacks. I think the actual underlying issue here is that while we pass the function type to chrome.events.Event, it's not actually used there. Internally Chrome doesn't really know about templated types so the actual addListener and removeListener methods just accept empty methods right now (i.e., they ignore the passed T extends Function).

We're still in beta, I'll aim to publish a new version today.

[Jan Hettenkofer]

Thanks for the reply!

1. I admit that QueryInfo and TabActiveInfo are somewhat special cases in that they are not explicitly mentioned in the documentation (AFAIK). Their names are carried over from @types/chrome.
   However, I believe having them exposed explicitly would increase the usefulness of chrome-types. E.g. for a situation like this:

function cb(info: chrome.tabs.TabActiveInfo) { /* ... */ }
chrome.tabs.onActivated.addListener(cb);

2. It would be fantastic if that could be fixed. As it is, I feel like this makes chrome-types more of an impediment than a helpful tool for development since developers would have to
   1. Know that the types are incorrect
   2. Look up the correct type
   3. Deactivate type checking on the line in question and manually specify the correct type

Both of these issues also mean that eventual changes in the API would go undetected by the compiler which I feel is a big part of the "raison d'être" for chrome-types.

I understand that chrome-types is still in beta and I hope that our feedback will help make it ready for prime-time.

[Sam Thorogood]

We've just published 0.0.8 which includes correct templated types for Event, as well as ContentSetting and ChromeSetting elsewhere. It also misses a bunch of missed const values (we previously specified them as just number, but now include their value).

Please take a look. Accurately reflecting Chrome's internal types (even in ways that are not ideal, perhaps so we can fix that) is definitely the goal here.

[bradley cushing]

I can confirm by testing with version 0.0.12 that types for the callback of chrome.tabs.onActivated.addListener is correctly typed as you mention above inline in your comment with the correct interface for the callback. However I did stumble upon another incomplete type, chrome.contextMenus.onClicked. I haven't found any others easily at the moment.

[Sam Thorogood]

We've spent some time updating the generator and now publish types which:

• support a correct template type for addListener and friends
• support declarative event listeners (where possible)
• we fixed an underlying issue (in the raw source data) with a few types including the OnClickData referenced by contextMenus.onClicked.
• support Promise.

The types are now MV3+ only (hence Promise) and hide MV2-only APIs. They only exist for Extensions, not the deprecated Platform Apps APIs.

[Ivan Trofimov]

I faced the same problem. In Promises implementation doesn't reflect with typings.
For instance:

export namespace cookies {
  export function get(
    details: CookieDetails
  ): Promise<{ cookie?: Cookie }> // Should be Promise<Cookie>
...
}

But callback implementations is right.

[Kyle T. Edwards]

I'm facing the same issue as @trofivan with the Promise return types - they all seem to include a wrapper object that isn't returned when actually calling the function. Will have to go back to using @types/chrome as a result 😞

[Sam Thorogood]

We're very sorry about the delay here: finally we've updated the script to correctly generate the return types for Promise-ified calls. This is fixed in chrome-types@0.1.41 which was just published.

e.g., cookies.get now looks like:

    /**
     * Retrieves information about a single cookie. If more than one cookie of the same name exists for the given URL, the one with the longest path will be returned. For cookies with the same path length, the cookie with the earliest creation time will be returned.
     *
     * @param details
     */
    export function get(
      details: CookieDetails,
    ): Promise<Cookie>;

[Sam Thorogood]

Please re-open or file new issues if we have other problems.

(With the note that we're unlikely to add interface types to replace object literals, which I do talk about above, unless that is something the Chrome team does themselves in unifying API calls.)