Issue with require() Call in ESM Environment

[Maddi02]

Description

I am encountering an issue where a require() call is made to an ECMAScript Module (ESM), specifically when trying to integrate the webdav library in a NestJS project. This occurs despite my project's TypeScript configuration set to use modern module resolution strategies. I would like to maintain my current project setup without changing to "type": "module" in package.json. I'm interested in understanding where this require() call is coming from and how to potentially resolve or refactor it to work with ESM modules correctly.

Any help is welcome. Thanks in advance :)

Environment

• NestJS Version: 10.3.2
• Webpack Version: [18.2.4]
• Node.js Version: [20.9.0]
• Operating System: [macOS 13.6]

tsconfig.json

{
  "compilerOptions": {
    "outDir": "../../dist/apps/api",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "target": "ES2022",
    "resolveJsonModule": true,
    "emitDecoratorMetadata": true,
    "isolatedModules": false,
    "esModuleInterop": true,
    "allowJs": true,
    "declaration": true,
    "composite": true
  }
}

[ascdi]

Same here, did you solve the Problem?

[PiotrSkon]

This... this is why I'm here :( Spent all day implementing a webdav solution and get this error right at the end.. won't compile. ExpressJs apps in an Nx workspace. Doing an import just like any other package.. fails with createClient

[Maddi02]

Even after several days of trying, I couldn't identify the problem. So, I built my own API using NestJS, which queries the username and password from a database and injects them with each request.

[perry-mitchell]

This is most likely NestJS doing something weird. I use this project daily on both the node side (ESM) and the browser side (compiled to CJS) without issue.

There is nothing special about the configuration here - the output is ESM only.

I'm unfortunately not at all familiar with Nest's bundling strategies so beyond this basic information I'm afraid I'm of no use. I'll be monitoring this thread regardless.

[perry-mitchell]

Closing as there isn't anything actionable here I'm afraid. I'd accept a PR adding back CJS beside the ESM output, but don't currently have bandwidth to do that myself. I don't believe that it would benefit much here though.