Replies: 2 comments
-
I agree...if we are using ESM, I think the Issues that seem related: #42201 |
Beta Was this translation helpful? Give feedback.
-
Just ran into this as well. It does seem strange there is no way to swap the type from As mentioned there may just need to be multiple entry points. For a quick hack fix you can diff --git a/globals.d.ts b/globals.d.ts
index 5f250062b0295a95916ad2acd6ae8141ff2b5e71..35f4cdd3fd6f6c6dd5f2f51ae5bbe93430695ea2 100644
--- a/globals.d.ts
+++ b/globals.d.ts
@@ -44,15 +44,6 @@ declare global {
var process: NodeJS.Process;
var console: Console;
- var __filename: string;
- var __dirname: string;
-
- var require: NodeRequire;
- var module: NodeModule;
-
- // Same as module.exports
- var exports: any;
-
/**
* Only available if `--expose-gc` is passed to the process.
*/ |
Beta Was this translation helpful? Give feedback.
-
Currently @types/node exposes globals that are supposed to be used only with CJS modules. When using ESM modules, this means we have autocompletion for them, and Typescript will compile fine.
At runtime though, it fails if we use them
__dirname is not defined in ES module scope
.Is there any way we could have Node type definitions without these CJS globals?
Would it make sense to have multiple entrypoints to this package, like @types/node/esm and @types/node/cjs, to separate ESM-only and CJS-only types?
Beta Was this translation helpful? Give feedback.
All reactions