Please consider adding a default export to your modules.

[wraithgar]

With the switch to ESM these packages are not exceptionally hard to get into existing CJS packages. If any of them need top level synchronous access, they are out of luck. This is of particular concern for npm itself, as it has some pretty unique requirements about how its tree is built (asynchronous imports are very dangerous during the npm install -g npm process, as things the current runtime may later need can have been deleted from the filesystem).

Under some cases we can get away with importing inside of a function instead of at the top level of a package, but for some of our packages this won't work, as they extend these classes and need these packages at the top level of their files, not inside another function.

We could refactor all of our code that uses these proxies to have generators returning these classes, but a simpler solution is to start exporting a default. This of course only works for packages that do not have a top level await. Fortunately this seems to be a case for these agents.

The alternatives here are going to be a mountain of work so we'd like to know soonish if this is going to be possible.

[KrayzeeKev]

Agreed. This simple modification to package.json (in https-proxy-agent, for instance) works fine.

  "exports": {
    "require": {
      "types": "./dist/index.d.ts",
      "default": "./dist/index.js"
    },
    "import": {
      "types": "./dist/index.d.ts",
      "default": "./dist/index.js"
    }
  },

require of ESM modules is fully supported in latest versions of Node as long as you don't use top-level await (which is ugly in modules anyway and isn't used here). This doesn't add any extra maintenance overhead to these modules ongoing. It just tells require where to find the files, just as it does for import.

[KrayzeeKev]

#407

[wraithgar]

The default export (ideally as an attribute in the package.json) seems more appropriate here, and is mentioned in the Node.js docs explicitly https://nodejs.org/api/esm.html#interoperability-with-commonjs

[KrayzeeKev]

@wraithgar Would you suggest this then? (just replace import with default):

"exports": {
    "default": {
      "types": "./dist/index.d.ts",
      "default": "./dist/index.js"
    }
  },

Or just add another default as so:

"exports": {
    "default": "./dist/index.js"
    "import": {
      "types": "./dist/index.d.ts",
      "default": "./dist/index.js"
    }
 },

[magicdawn]

"exports": {
-  "import": {
+  ".": {
    "types": "./dist/index.d.ts",
    "default": "./dist/index.js"
  }
}

esm only, forget import & require

[KrayzeeKev]

@magicdawn Sure, I can live with that. Do you even need the "."? Does this work as desired?

"exports": {
    "types":"./dist/index.d.ts",
    "default": "./dist/index.js"
},

[magicdawn]

yes, I upgraded proxy-agent to v7.0.0 inside a Nest.js project which is cjs
(package.json has no type:module, tsconfig compilerOptions.module=nodenext).
I saw news about Nest.js is working on esm emit, but currently it's cjs for resolve or emit.

replace import with ., then restart tsserver then in vscode error gone.
I did not test the tsc behavior, then I downgrade proxy-agent to v6.

keeping . just for exports."./package.json" = "./package.json" too.

[KrayzeeKev]

@TooTallNate I know you don't want to support CJS and I'm not asking for that. But the current package.json actively excludes the ESM package from being required . I'm just after a small change to allow it. Current versions of Node (which your engines directive limits usage to, which is fine) allow ESM to be required. But these modules explcitly say import only.

These new features allow modules to be ESM only and it also allows people like me (600+ CJS files) to use ESM modules without having to rewrite hundreds of source files. We'll get there but it's a major investment of resources (probably be the TS rewrite). Until then, I'd like to use the latest modules. My security department is really quite pedantic about that.

So it's just a tiny change to package.json and then you get to ignore it. You don't have to support Node < 22 and your engines says so. So no harm there. I'm just asking to not block require explicitly.