Using Electron's new official TypeScript Definitions

[zeke]

• I have a question that is inappropriate for StackOverflow.
• I want to talk about electron/electron.d.ts
• The authors of that type definition are cc'd @vvakame @rhysd @miniak

👋

I work on the Electron team at GitHub. We are in the process of generating an electron.d.ts file as part of our release process, and will soon be bundling it in the electron (and electron-prebuilt) npm package. electron-userland/electron-prebuilt#209

I am attempting to remove the existing Electron definitions from this repository to prevent issues/collisions for existing users of the third-party definition file. I'm following the steps outlined at https://github.com/DefinitelyTyped/DefinitelyTyped#removing-a-package, but I do not see a notNeededPackages.json file as mentioned in those instructions. Am I missing something?

cc @MarshallOfSound @niik

[niik]

but I do not see a notNeededPackages.json file as mentioned in those instructions. Am I missing something?

I think that's because you're looking at the master branch but all definitions that doesn't target typings live in the types-2.0 branch. See https://github.com/DefinitelyTyped/DefinitelyTyped/blob/types-2.0/notNeededPackages.json

[rhysd]

@zeke

Hi, that's great to see the official TypeScript support for Electron!

Alhtough this should not be discussed here, but I have some concerns about removing current definition file immediately. I want to know that the new type definition actually can replace electron/index.d.ts in this repo.

• Is the new type definition well-tested? I think electron-main-tests.ts and electron-renderer-tests.ts are available for it (although it doesn't cover all of APIs)
• The type definition exports proper definitions? Some types (e.g. Type of callback of IPC events, interface for WebContents objects, ...) should be imported from outside to be used in user code.

I want to see the generated type definition to know that it has enough quality to replace type definition in DefinitelyTyped.

[MarshallOfSound]

@rhysd I'm currently in the process of moving city so my computer is currently in a box 😢

When I unpack though I'll test the generated definition against those files and ensure it works 👍

FWIW I have already tested the definition against a few typescript projects I have and against VS Code and all of them required minimal changes to work with the new definitions (10 - 40 changes) mostly due to type names changing. I.e. In the current definition we have Electron.ShowOpenDialogOptions and in the generated one we have Electron.OpenDialogOptions. Small names changes like that are a result of the auto-generation of the typescript definition and take a few minutes to update across your project.

If you want to take a look at the definition before I get setup again (or before @zeke sees this) you can just clone https://github.com/electron/electron-definitelytyped and run npm run demo and it will generate you an electron.d.ts file. 👍

[MarshallOfSound]

@rhysd So I borrowed someones laptop and took a look. With the latest docs and the latest generator I get 3 errors on the main tests and like 8 on the renderer ones (The renderer errors are only webview related).

The renderer ones are to be expected as we don't export the webview usage as an actual API in our JSON file. And the main tests appear to be due to the WebRequest doc not be parsed at all.

Will probably need to discuss how best to handle the WebView API stuff somewhere (slack maybe). I have a sneaky idea that we can just inherit from WebContents. Hit me up on Slack if you have questions / want to discuss it 👍

EDIT: Link to generated file --> https://gist.github.com/MarshallOfSound/8b1b1aa0773fab1a9178cc2d1025dadd

[rhysd]

@MarshallOfSound Thank you for detailed explanation. It sounds nice 👍 I'll also try it in my apps.

[MarshallOfSound]

@rhysd @niik Want to try get the ball rolling on this again. The linked gist has been updated with the latest generated typings:

https://gist.github.com/MarshallOfSound/8b1b1aa0773fab1a9178cc2d1025dadd

And now passes all of the tests currently in this repository.

Looking for the best way forward RE moving towards a typings file that we publish rather than the manually maintained one here. We are almost at the point where we can ship an electron.d.ts file with each of our Electron releases (just need to do some wiring in our releaser). Few outstanding questions though.

• Is there a way we can publish our typings to the @types namespace? Publish @types/electron electron/typescript-definitions#10
• What's the formal process for removing these typings / forwarding them to our typings?

[miniak]

I would like to review the auto-generated file thoroughly. Last time I've checked (two weeks ago), there were still some issues.

[zeke]

@miniak that would be great.

Please report anything you find at https://github.com/electron/electron-typescript-definitions/issues, and note that there are already a few issues filed there.

[joshaber]

Is there a way we can publish our typings to the @types namespace? electron/typescript-definitions#10

Yep, submit a PR to https://github.com/DefinitelyTyped/DefinitelyTyped. But you shouldn't need to do that. See below.

What's the formal process for removing these typings / forwarding them to our typings?

TypeScript will prefer the typing we include in Electron over any typings provided by @types. So users won't need to do anything with @types. So long as the typing is in Electron and pointed to by the package.json It'll Just Work®.

The trick will be communicating to users that they no longer need @types for Electron and can remove that dependency.

[zeke]

users won't need to do anything with @types

It was suggested (by @felixrieseberg, I believe) that people should still have a way to install the official Electron definitions without having to include all of electron as a dependency.

[zeke]

We're just about to ship an official electron.d.ts file bundled with the electron npm package. It's currently available in a beta. To try it, run npm i electron@1.7.1 or npm i electron@beta.

WIP blog post: electron/electronjs.org-old#731

As I mentioned earlier, we can continue publishing the new auto-generated types here as @types/electron, as folks may find it useful to sometimes use Electron's type definitions without also depending on electron itself.

[zeke]

@miniak if you can help update the typings here, that would be awesome!

You also mentioned updating the typings registry. Is that still something you can take care of?

[zeke]

cc @DanielRosenwasser

[DanielRosenwasser]

The trick will be communicating to users that they no longer need @types for Electron and can remove that dependency.

The types publisher has a mechanism for this. For example, if I npm install @types/redux, I'll get...

WARN deprecated @types/redux@3.6.0: This is a stub types definition for Redux (https://github.com/reactjs/redux). Redux provides its own type definitions, so you don't need @types/redux installed!

I don't know the extent to which you'll need to worry about the registry. If it's in the package itself you should be fine.

[callumlocke]

Can this issue be closed yet?