electron.d.ts does not work with @types/node v13.1.0

[rhysd]

Preflight Checklist

• [x] I have read the Contributing Guidelines for this project.
• [x] I agree to follow the Code of Conduct that this project adheres to.
• [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

• Electron Version:
  
  
  
  • 7.1.7
  
  
• Operating System:
  
  
  
  • macOS 10.14
  
  
• Last Known Working Electron version:
  
  
  
  • N/A
  
  

Expected Behavior

Can compile successfully the TypeScript code

Actual Behavior

Compilation error

main/window.ts:14:5 - error TS2339: Property 'removeAllListeners' does not exist on type 'BrowserWindow'.

14 win.removeAllListeners();
       ~~~~~~~~~~~~~~~~~~

node_modules/electron/electron.d.ts:1655:31 - error TS2689: Cannot extend an interface 'NodeJS.EventEmitter'. Did you mean 'implements'?

1655   class BrowserWindow extends NodeJS.EventEmitter {
                                   ~~~~~~

EDIT: Added entire compile error messages thanks to https://github.com/electron/electron/issues/21612#issuecomment-568691944

To Reproduce

Try to compile following code with the latest TypeScript compiler and latest @types/node package.

import { BrowserWindow } from 'electron';
const win = new BrowserWindow();
win.removeAllListeners();

Package versions:

• typescript: 3.7.4
• @types/node: 13.1.0

Screenshots

Nothing

Additional Information

I have investigated this issue and found the cause.

@types/node v13 has breaking change affecting NodeJS.EventEmitter from v12. It was changed from class to interface. Now, EventEmitter can only be extended by interfaces. I confirmed electron.d.ts worked fine with @types/node v12. The change is here:

https://github.com/DefinitelyTyped/DefinitelyTyped/commit/c47a34ead1637f6f34e7d630dc88ea3f6e5562cb#diff-a2f9a5377787f7084c7f52b20c0108cfR540

However, classes such as BrowserWindow in electron.d.ts try to extend EventEmitter so it is causing this issue.

May be related to #21475

[rhysd]

I believe we can no longer use NodeJS.EventEmitter and we need to use import { EventEmitter } from 'events'; for this. However, import statement is not available since <reference/> is used and we currently rely on Electron namespace. It probably requires rewriting to use import/export statements instead of <reference/>/namespace in electron.d.ts.

[basarat]

The @types/node for node 13 also result in the following type error:

Cannot extend an interface 'NodeJS.EventEmitter'. Did you mean 'implements'?

More

https://github.com/DefinitelyTyped/DefinitelyTyped/commit/c47a34ead1637f6f34e7d630dc88ea3f6e5562cb#r36559684

[rhysd]

Yeah, the message is caused by the above compile error. And implements is (of course) not available for us. I included the error message in description of this issue. Thanks!

[amirburbea]

Running into same issue

[vladimiry]

It's expected as Electron v7 comes with node v12, so use the most recent @types/node v12.

[amirburbea]

No @vladimiry . That's not how it works - there is no direct tie between @types/node and the version of nodejs. Many packages (not just electron) reference @types/node using a version range (such as "^8.0.0" or worse "*"), so when one of them upgrades everyone really must be able to.

Electron incompatibility with the latest @types/node makes it hard to upgrade any package in my solution

[vladimiry]

there is no direct tie between @types/node and the version of nodejs

Can you provide a source?

[amirburbea]

Even if I can't (which I'm sure I could if I spent the time), the problem is most solutions reference many packages that reference @types/node via a version range.

The problem is electron types declare a class extends NodeJS.Emitter but that it's an interface now so the correct syntax is implements NodeJS.Emitter or more correctly extends events.EventEmitter which works with old node and new node

[rhysd]

It's expected as Electron v7 comes with node v12, so use the most recent @types/node v12.

At least Electron v8 beta and v9 nightly have the same issue. Is there any plan to fix this incompatibility between electron.d.ts and @types/node v13 before upgrading node version of Electron? I concern the case where electron.d.ts is not fixed but Electron's node version is upgraded to v13.

[vladimiry]

At least Electron v8 beta and v9 nightly have the same issue.

Electron 8.0.0-beta.5 comes with Node 12.13.0, didn't try the 9-nightly build.

[rhysd]

My point is whether the incompatibility is recognized by team and tracked anywhere for fix until node v13 upgrade.

[cyfrost]

Is there a temporary workaround to this? I'm unable to compile a typescript project due to the error listed in OP.

[amirburbea]

Force all references in your package.json and yarn.lock to use @types/node
12.21.12. This is an unacceptable but hopefully temporary scenario

There's a few people trying to act as though the problem is electron 7 uses
node 12 and not 13. They're just plain wrong. The problem is the use of
extends vs implements keywords on classes/interfaces. Again you have
version ranges (for example, redux says @types/node:^8)

On Wed, Dec 25, 2019, 8:33 AM Cyrus Frost [e-mail] wrote:

Is there a temporary workaround to this? I'm unable to compile a
typescript project due to the error listed in OP.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/21612?email_source=notifications&email_token=AAQGPCWYY4R2NEQ6OW23OYLQ2NOJLA5CNFSM4J63DZ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHULURI#issuecomment-568900165,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQGPCTIGMVJ4QSYKYF7TKTQ2NOJLANCNFSM4J63DZ5Q
.

[cyfrost]

Force all references in your package.json and yarn.lock to use @types/node 12.21.12. This is an unacceptable but hopefully temporary scenario There's a few people trying to act as though the problem is electron 7 uses node 12 and not 13. They're just plain wrong. The problem is the use of extends vs implements keywords on classes/interfaces. Again you have version ranges (for example, redux says @types/node:^8)
…
On Wed, Dec 25, 2019, 8:33 AM Cyrus Frost @.*> wrote: Is there a temporary workaround to this? I'm unable to compile a typescript project due to the error listed in OP. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21612?email_source=notifications&email_token=AAQGPCWYY4R2NEQ6OW23OYLQ2NOJLA5CNFSM4J63DZ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHULURI#issuecomment-568900165>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQGPCTIGMVJ4QSYKYF7TKTQ2NOJLANCNFSM4J63DZ5Q .

This workaround works! Thanks! Minor correction: the @types/node version in package.json should be 12.12.21 instead of 12.21.12.

[vladimiry]

Looks like we got thoughtful TypeSript and semver versioning expert here ==> @amirburbea

The problem is the use of
extends vs implements keywords on classes/interfaces.

Electron npm module is shipped with @types/node@^12.0.12 at the moment so it's totally fine that they do extends NodeJS.EventEmitter since NodeJS.EventEmitter is a class in @types/node prior v13.

It's expected as Electron v7 comes with node v12, so use the most recent @types/node v12.

No @vladimiry . That's not how it works

Electron even has automated test added for verifying that major versions of bundled node and @types/node got matched, see https://github.com/electron/electron/blob/f426ad1b5914295f9684036fb55f918c1b074900/spec-main/types-spec.ts

there is no direct tie between @types/node and the version of nodejs

There's a few people trying to act as though the problem is electron 7 uses
node 12 and not 13.

For curious persons, checking @types/node and nodejs versions correlation:

You can clone the https://github.com/DefinitelyTyped/DefinitelyTyped and execute git log -L 1,1:types/node/index.d.ts --pretty=oneline to see that commit message corresponds to first-line/header of the types/node/index.d.ts file change. So this pretty much indicates that version of @types/node corresponds to nodejs version.

c47a34ead1637f6f34e7d630dc88ea3f6e5562cb feat(node): v13 (#40927)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 12.12
+// Type definitions for non-npm package Node.js 13.1
a91a9a49ded5dd536a4bb0d2098eb1b0de1eadcd feat(node): v12.12 (#39914)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 12.11
+// Type definitions for non-npm package Node.js 12.12
cbe21d594a3b24fd1b93719958bc90ab6007ac51 feat(node): v12.11 (#39116)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 12.7
+// Type definitions for non-npm package Node.js 12.11
3f6627ea70b804317b90c0212b2055eff0a67a6f feat(node): v12.7 (#37217)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 12.6
+// Type definitions for non-npm package Node.js 12.7
4db4c26549c7edd452c46492f3421d5dce3200b0 feat: node v12.5 (#36562)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 12.0
+// Type definitions for non-npm package Node.js 12.6
18b13d1f4a6830861bf4f693a706dcde4aa8b21f feat(node): v12 (#34952)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 11.13
+// Type definitions for non-npm package Node.js 12.0
e6625ba155c7529e8bfb751a23b0d12bb8fe1ec5 feat(node): v11.13

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 11.12
+// Type definitions for non-npm package Node.js 11.13
923fe86451333613c015358a7447ed914945427f feat(node): v11.12 (#33967)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 11.11
+// Type definitions for non-npm package Node.js 11.12
bac137341280d31ee0f8159ddad66b0fa144e5fa feat(node): v11.11

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 11.10
+// Type definitions for non-npm package Node.js 11.11
80fb3119f40c6b70e4a9632887980036e36f6b2b feat(node): v11.10

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for non-npm package Node.js 11.9
+// Type definitions for non-npm package Node.js 11.10
608c146d8982a2ff7307f0a3bdddd6d55cb1a63e Mark non-npm packages

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for Node.js 11.9
+// Type definitions for non-npm package Node.js 11.9
c8dadc971b8524704c4b39243780e294d7a15f12 feat(node): enable strict null checks and add SharedArrayBuffer

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for Node.js 11.6
+// Type definitions for Node.js 11.9
e69abd8af13b4dd17259e72898b118102993915d feat(node): v11.6

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for Node.js 10.12
+// Type definitions for Node.js 11.6
df80e09009547e5556c09a16f3c715ecf9aff325 feat(node): 10.12 (#29689)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for Node.js 10.11
+// Type definitions for Node.js 10.12
352f2a6a39758bead6182a0d04bcf0b8d7c7a381 chore(node): apply lint

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for Node.js 10.11.x
+// Type definitions for Node.js 10.11
e17d39e6b09a1e44d7dd69fa22b3da42c7156948 feat(node): 10.11

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for Node.js 10.10.x
+// Type definitions for Node.js 10.11.x
9061b19a3c7d676fc4aeacc825ab7790edad13c6 types(node): add changes from 10.10 (#28918)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for Node.js 10.9.x
+// Type definitions for Node.js 10.10.x
374598de675780b1312912d43dff88f9fbfcf0d8 [node] Add http[s] request/get variants for 10.9.0 (#28193)

diff --git a/types/node/index.d.ts b/types/node/index.d.ts
--- a/types/node/index.d.ts
+++ b/types/node/index.d.ts
@@ -1,1 +1,1 @@
-// Type definitions for Node.js 10.7.x
+// Type definitions for Node.js 10.9.x
3c8f15080c5728847c627ba07a623276ef1869ab add timeout to http.AgentOptions (#21346 
...

Regarding @types/node v13. You could see that what they do there with like 160 d.ts files of different libraries to make them compatible with @types/node@^13 is replacing

declare class SomeClass extends NodeJS.EventEmitter

with

import { EventEmitter } from 'events'; 
declare class SomeClass extends EventEmitter { 

So @electron will probably follow the same way one day when they move to @types/node@^13.

CC @MarshallOfSound

[rhysd]

I believe replacing <reference/> with import/export can start without waiting for Node.js v13 upgrade of Electron since the replacement is also valid for @types/node v12.

I concern this because it requires many changes in electron.d.ts. Currently import statement is not available in electron.d.ts due to <reference> and namespace usage. So we can't simply replace NodeJS.EventEmitter with import { EventEmitter } from 'events'. As I said at first comment of this issue, at first it is necessary to remove <reference> and add export to all public APIs for use of import statement. These would be breaking changes in electron.d.ts so we must add them at major version up of electron package.

[andrewbranch]

From the DefinitelyTyped side, I’ve confirmed this was a correct change. The typings previously allowed this:

new NodeJS.EventEmitter();

which of course does not exist at runtime.

Currently import statement is not available in electron.d.ts due to <reference> and namespace usage.

Sort of—the deal is that when you have any import or export declaration in a file, that file becomes a module, so declarations are no longer global. If you need global declarations and imported stuff in the same file, you can solve this in two ways:

1. Import what you want (so your file becomes a module), then wrap global declarations in a declare global { ... } block.
2. Instead of doing import { EventEmitter } from 'events', you can use type EventEmitter = import('events').EventEmitter. But, this syntax is only available in TypeScript 2.9 and later.

[amirburbea]

I think it's safe to assume if someone is using a recent version of @types/node, they're probably using a semi recent version of typescript (2.9 came out over a year ago now)

[andrewbranch]

That’s not really the issue—the decision for electron to make is whether they need to support _anyone_ with TS 2.8 or earlier, because they’re presumably only going to ship the same electron.d.ts to everyone. They can’t ship the new syntax conditionally upon whether the user has a recent @types/node.

[amirburbea]

I think it's safe to move to 3.0 as a baseline for electron's use of typescript. That would be 18 months old already. (TS3.0 released July2018, TS 2.8 was March2018 - not even a huge lag time between them)

[andrewbranch]

I have no real opinion on how this should be dealt with, but as the person who merged the PR that caused this issue, I just wanted to

• let the electron maintainers know that this was an intentional change from @types/node and it’s probably not going to go away
• offer potential methods for fixing it on their side

[andrewbranch]

Oh, and I totally missed the fact that there _is_ a global events. So yeah, replacing NodeJS.EventEmitter with events.EventEmitter is even simpler, which @amirburbea already mentioned. Sorry to miss that 👍

[rhysd]

I did not know that the dynamic import syntax is available in ambient context. Thank you for letting me know!

Yeah, global { ... } block is already used in @types/node v12 actually. So it should be safe to use it in electron.d.ts. I think we can choose easier way type EventEmitter = import('events').EventEmitter.

[rhysd]

I had an experiment that adds type EventEmitter = import('events').EventEmitter; in namespace Electron { ... } block and removes NodeJS. from class BrowserWindow extends NodeJS.EventEmitter. However, I got following error. I think type EventEmitter = ... only imports type but extends requires a value so it is unavailable here.

node_modules/electron/electron.d.ts:1657:31 - error TS2693: 'EventEmitter' only refers to a type, but is being used as a value here.

1657   class BrowserWindow extends EventEmitter {
                                   ~~~~~~~~~~~~

[amirburbea]

What about class BrowserWindow extends import('events').EventEmitter

On Tue, Dec 31, 2019, 8:41 AM Linda_pp [e-mail] wrote:

I had an experiment that adds type EventEmitter =
import('events').EventEmitter; in namespace Electron { ... } block and
removes NodeJS. from class BrowserWindow extends NodeJS.EventEmitter.
However, I got following error. I think type EventEmitter = ... only
imports type but extends requires value so it is unavailable here.

node_modules/electron/electron.d.ts:1657:31 - error TS2693: 'EventEmitter' only refers to a type, but is being used as a value here.

1657 class BrowserWindow extends EventEmitter {
~~~~

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/21612?email_source=notifications&email_token=AAQGPCWQTNSCLNGH77BAGJ3Q3NDYZA5CNFSM4J63DZ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH4HFZI#issuecomment-569930469,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQGPCQEYHIK4RAH7C5PBBTQ3NDYZANCNFSM4J63DZ5Q
.

[rhysd]

It does not work because import(...) syntax returns Promise value.

[rhysd]

So yeah, replacing NodeJS.EventEmitter with events.EventEmitter is even simpler, which @amirburbea already mentioned.

Where is the events global value defined? I simply replaced NodeJS.EventEmitter with events.EventEmitter but got following error:

node_modules/electron/electron.d.ts:1655:31 - error TS2552: Cannot find name 'events'. Did you mean 'Event'?

1655   class BrowserWindow extends events.EventEmitter {
                                   ~~~~~~

[amirburbea]

You need to first import events (import events from 'events' or maybe const
events = require('events'))

On Tue, Dec 31, 2019, 9:00 AM Linda_pp [e-mail] wrote:

So yeah, replacing NodeJS.EventEmitter with events.EventEmitter is even
simpler, which @amirburbea https://github.com/amirburbea already
mentioned.

Where is the events global value defined? I simply replaced
NodeJS.EventEmitter with events.EventEmitter but got following error:

node_modules/electron/electron.d.ts:1655:31 - error TS2552: Cannot find name 'events'. Did you mean 'Event'?

1655 class BrowserWindow extends events.EventEmitter {
~~

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/21612?email_source=notifications&email_token=AAQGPCQI7Z7KPIVJG6ZN2UDQ3NF7JA5CNFSM4J63DZ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH4HZWY#issuecomment-569933019,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQGPCWE4SZAMOWGPYMO7J3Q3NF7JANCNFSM4J63DZ5Q
.

[rhysd]

Yeah, so I think we need to choose the first option @andrewbranch showed. As I commented above, import statement is not available in current electron.d.ts because it is not a module. To use it, we need to remove <reference> and namespace and need to use export instead. It is a breaking change of electron.d.ts so timing is important.

[andrewbranch]

Sorry, I should have tried the code I said before saying it. This is what I meant @rhysd:

However, note that this makes EventEmitter appear global, which may not be desirable. I think declare global is a better option all around.

---

Where is the events global value defined?

I was mistaken—I realized that events is globally available in node at runtime, like other built-in modules, and assumed it had a type declaration, but it does not.

[rhysd]

Thank you for your support @andrewbranch! I finally could fix electron.d.ts as follows without breaking change. I confirmed tsc compiled successfully.

https://gist.github.com/rhysd/c8d68f0399a84a5383aee67857642852

I will try to fix auto-generation logic.

[andrewbranch]

FYI, I think @sandersn has been working on this too.

[rhysd]

Is he already trying to fix electron.d.ts? Or fixing other packages?

[andrewbranch]

I believe he was working on the electron.d.ts auto-generation, but I don’t know how far he got.

[rhysd]

ok, I will try to check out issues and pull requests before starting to work on this.

[rhysd]

I have raised a pull request at https://github.com/electron/typescript-definitions/pull/163 for this issue.

[sandersn]

I've got another, pre-2.9-compatible one at electron/typescript-definitions#164, but I would only use it if old Typescript compatibility is very important. As I commented on electron/typescript-definitions#163, the numbers we see from VS and VS Code indicate that it's probably not.

[j-o-d-o]

I got the same issue also on the LTS version (v12.14.0). Is there a workaround until the PR is merged other than downgrading node js version?

[oriSomething]

@j-o-d-o If your using yarn, add to package.json this:

 "resolutions": {
    "@types/node": "12.12.6"
  },

Otherwise, it might resolve version 13 implicitly by some deps

[SeqSEE]

Same issue for me when using instructions from : https://www.electronforge.io/templates/typescript-template

I was able to work around this for now by doing the follow in the initialized directory:

npm install @types/node --save

then editing package.json changing

"dependencies": { "@types/node": "^13.1.4", "electron-squirrel-startup": "^1.0.0" }

to

"dependencies": { "@types/node": "12.12.6", "electron-squirrel-startup": "^1.0.0" }

and finally running

npm install && npm start

[skorunka]

Downgrading to version 12.12.6 helped.

[olegchir]

And what should we do if we want to use node 13?

[rhysd]

PR for fixing this issue was already created. Wait for the fix being released

[andrewrynhard]

FWIW Seeing this with 12.12.24. Installing 12.12.21 fixed it.

[rhysd]

FWIW Seeing this with 12.12.24. Installing 12.12.21 fixed it.

No. I confirmed that v12.12.24 did not cause this issue.

I also checked node/v12 directory but NodeJS.EventEmitter is still a class as follows:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/6f1f5c8b4f2d085c199dc786efd27eeecdc05667/types/node/v12/globals.d.ts#L611

So current @types/node@12 does not cause this.

[amirburbea]

Any idea when this will be released within electron 7.x?

On Wed, Jan 29, 2020, 10:33 PM Samuel Attard [e-mail]
wrote:

Closed #21612 https://github.com/electron/electron/issues/21612 via
electron/typescript-definitions#163
https://github.com/electron/typescript-definitions/pull/163.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/21612?email_source=notifications&email_token=AAQGPCVGBYHYTYWCIIN4G4LRAJKDJA5CNFSM4J63DZ52YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOWJKXOZI#event-2991945573,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQGPCQGYV42DTDJPPZKGUTRAJKDJANCNFSM4J63DZ5Q
.

[OmarB97]

What's the current recommended fix for this? Is this completely resolved now?

[SeqSEE]

What's the current recommended fix for this? Is this completely resolved now?

this is what worked for me
https://github.com/electron/electron/issues/21612#issuecomment-570892464

[remusao]

I can confirm that this issue is now resolved using latest release v8.0.0. Thank you!

[amirburbea]

This is not resolved @remusao !

I can confirm that this issue is now resolved using latest release v8.0.0. Thank you!

Opening up [email protected]'s electron.d.ts I still see

class BrowserWindow extends NodeJS.EventEmitter which again needs to be implements

I thought the PR was merged and that this is no longer going to be a problem, yet here we are. And now thanks to your incorrect comment, they went ahead and closed the issue!!!

[remusao]

This is not resolved @remusao !

I can confirm that this issue is now resolved using latest release v8.0.0. Thank you!

Opening up [email protected]'s electron.d.ts I still see

class BrowserWindow extends NodeJS.EventEmitter which again needs to be implements

I thought the PR was merged and that this is no longer going to be a problem, yet here we are. And now thanks to your incorrect comment, they went ahead and closed the issue!!!

@amirburbea First of all, the issue was closed 5 days ago, whereas my comment is from today (so I am for nothing into the status of this issue).

Secondly, in my particular case, the latest release fixed the type error. It could be that we are having two different issues; what I know is that I was able to update my library to latest electron 8 this morning and it type-checked, whereas I had the type error before. I did not dig further though :)

If the issue is not fixed, then gently point it out again with details and I am sure the team will have a look.

[amirburbea]

Fine, mea culpa - it's not your fault. Nevertheless, the attempt to resolve this issue by the electron team is woefully inadequate.

It seems that what happened is that electron@8.0 now specifies specifically @types/node 12 in its package json - but otherwise makes no attempt to use implements as opposed to extends (which would have worked for @types/node 12 or 13) , and consequently yarn made a node_modules/@types/node directory underneath the node_modules/electron directory. The problem is if some other library called for @types/node 13 or * (which brings in ^13), typescript only uses one of the two folders (not both).

I ended up with the following folder structure and at compile time typescript only accessed one @types/node (the root one which is 13.x)

node_modules
> @types
> > ...
> > node (13.x)
> electron (8.0.0)
> > node_modules
> > > @types
> > > > node (12.x)
> ...

[remusao]

I am not very familiar with the release process of Electron, but since the issue has been addressed in this project: https://github.com/electron/typescript-definitions/releases/tag/v8.6.6. Maybe it will land in Electron soon?

[vladimiry]

It's merged in typescript-definitions project https://github.com/electron/typescript-definitions/pull/163 but Electron project didn't get the update yet.

typescript only uses one of the two folders (not both).

Typescript actually can be configured to use typings you like more.

[romanov]

npm install @electron/typescript-definitions --save

copy types/node => node_modules/types

any CLI command to update it?

[marcschroeder]

Is there a workaround to this issue at the moment? Is this fixed in some version? We tried the latest and nightly build and both did not fix the issue.

[MarkSill]

@marcschroeder If you don't need Node 13 typings, you can add @types/node@12 to your dependencies.

e.g. npm i --save-dev @types/node@12 or yarn add -D @types/node@12

[marcschroeder]

What electron version should I use? With 8.0.2 I get the following issue: Module not found: Error: Can't resolve 'fs'

[marcschroeder]

Any ideas anyone?

[remusao]

Could a maintainer of Electron (or someone else who knows) maybe clarify what the release cycle of type definitions looks like? There were multiple releases for Eletron 8.x in the past weeks, none of which shipped with the updated definitions. Does it mean they will ship with Electron 9 (is this considered a breaking change)? Or is this update dependent on something else?

[marcschroeder]

Any updates on this issue?

[vladimiry]

I think someone concerned should consider placing a new issue as this one seems to be ignored since got closed (closed mistakenly or not is another matter).

[amirburbea]

It's been fixed in a PR for electron types. But those are not in electron
yet. My guess is it will be in electron 9

On Thu, Mar 12, 2020, 12:22 PM Vladimir Yakovlev [e-mail]
wrote:

I think someone concerned should consider placing a new issue as this one
seems to be ignored since got closed (closed mistakenly or not is another
matter).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/21612#issuecomment-598312507,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQGPCWQNFSU3CKHDMOU6GTRHEK63ANCNFSM4J63DZ5Q
.

[marcschroeder]

Is there already a beta version for electron 9?

[vladimiry]

@amirburbea

It's been fixed in a PR for electron types. But those are not in electron

It's merged in typescript-definitions project electron/typescript-definitions#163 but Electron project didn't get the update yet.

My guess is it will be in electron 9

Nope since should be 8.6.6 https://github.com/electron/electron/blob/4b9f2bc72599f99f0ac95bb8b3d63e1c2d146c72/yarn.lock#L43-L44

Is there already a beta version for electron 9?

Yes.

[marcschroeder]

So I now switched to Electron 9 and used the following hack to get around using any types from electron:
const electron = window'require';
electron.remote.app.setLoginItemSettings({
openAtLogin: true,
});

[yoDon]

Workaround:

• Go back to Electron 6.x.x (don't blame me, I'm just a guy trying to find a "solution" here)
• npm install
• open package-lock.json
• search for "@types/node":
• find the entry under electron (the values I show below are for 6.1.9)

      "requires": {
        "@types/node": "^10.12.18",
        "electron-download": "^4.1.0",
        "extract-zip": "^1.0.3"
      },
      "dependencies": {
        "@types/node": {
          "version": "10.17.17",
          "resolved": "https://registry.npmjs.org/@types/node/-/node-10.17.17.tgz",
          "integrity": "sha512-gpNnRnZP3VWzzj5k3qrpRC6Rk3H/uclhAVo1aIvwzK5p5cOrs9yEyQ8H/HBsBY0u5rrWxXEiVPQ0dEB6pkjE8Q==",
          "dev": true
        }
      }

• Modify the requires reference, remove the dependencies block (and the comma that was between requires and dependencies)

      "requires": {
        "@types/node": "*",
        "electron-download": "^4.1.0",
        "extract-zip": "^1.0.3"
      }

• In the file system remove node_modules/electron/node_modules

[vladimiry]

@electron/typescript-definitions version has just been bumped in lock file https://github.com/electron/electron/commit/0d2e9679600bc757eeb34356dc9c3779d0edccee#diff-8ee2343978836a779dc9f8d6b794c3b2 so I guess we can expect the updated d.ts to come with next release.

[IceSentry]

Why is this closed? This still doesn't work

[saostad]

I still have this problem. I can't keep my @types/node to 12.12.21 for long time.
could you please reopen the issue and fix it?

[vladimiry]

I recommended before to open a new issue since in my experience closed issues don't get reopened here.

[skorunka]

Anyway how to make it working? Having downgraded "@types/jest" to "25.1.4" is not long-term fix :(. Thank you.

[vladimiry]

Right now only electron v10 is shipped with updated definitions (it uses @electron/typescript-definitions@^8.7.2).

[dropsonic]

Run npm install --save --save-exact @types/node@^12.12.6. It works afterward (even with Electron v8.2.5).

[vladimiry]

It works afterward (even with Electron v8.2.5).

Of course it works this way. The point of this issue is that other deps used in the project require node@^13.

[amirburbea]

Thank you @vladimiry, I've been following this thread for 4 or so months and every once in a while someone feels compelled to write how they got this to work by using @types/node 12 with some npm or yarn command. As you said, that's the point of this whole thread.

[saostad]

same problem even with electron v9.0.0

[saostad]

guys this is closed issue and nobody will look at it.
I oped another issue please add your comments on that.

[rhysd]

As it is said repeatedly in this issue thread, the fix for electron.d.ts for Node v13 is already there. I had made a PR and it was merged. But Node.js integrated to Electron is still v12 even in Electron v9. So using @types/node@12 is proper and the fix is not included in Electron v9. You should use @types/node@12.

[StationedInTheField]

So I have the same problem trying to use fs in my Angular9/Electron9 desktop app, seems to me like the best workaround would be to require all the necessary classes (in my case electron.remote) in a preload.js instead of downgrading the node version just for a single module (electron)?

[saostad]

upgrade to electron 10, problem solved!