Can't use d3 lib with NestJS

[dminglv]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Hello! I have problems with using the d3 package.

Require package use ES Module, but NestJS don't support this and I cant't use this module.

Minimum reproduction code

https://github.com/dminglv/nestjs-d3

Steps to reproduce

No response

Expected behavior

The third-party library is not imported (d3)

Package

• I don't know. Or some 3rd-party package
• @nestjs/common
• @nestjs/core
• @nestjs/microservices
• @nestjs/platform-express
• @nestjs/platform-fastify
• @nestjs/platform-socket.io
• @nestjs/platform-ws
• @nestjs/testing
• @nestjs/websockets
• Other (see below)

Other package

d3

NestJS version

9.0.11

Packages versions

"dependencies": {
    "@nestjs/common": "^9.0.11",
    "@nestjs/core": "^9.0.11",
    "@nestjs/platform-express": "^9.0.11",
    "d3": "^7.6.1",
    "reflect-metadata": "^0.1.13",
    "rimraf": "^3.0.2",
    "rxjs": "^7.5.6"
  },
  "devDependencies": {
    "@nestjs/cli": "^9.1.2",
    "@nestjs/schematics": "^9.0.3",
    "@nestjs/testing": "^9.0.11",
    "@types/d3": "^7.4.0",
    "@types/express": "^4.17.13",
    "@types/jest": "29.0.0",
    "@types/node": "^18.7.15",
    "@types/supertest": "^2.0.12",
    "@typescript-eslint/eslint-plugin": "^5.36.1",
    "@typescript-eslint/parser": "^5.36.1",
    "eslint": "8.22.0",
    "eslint-config-prettier": "^8.5.0",
    "eslint-plugin-prettier": "^4.2.1",
    "jest": "29.0.2",
    "prettier": "^2.7.1",
    "source-map-support": "^0.5.21",
    "supertest": "^6.2.4",
    "ts-jest": "28.0.8",
    "ts-loader": "^9.3.1",
    "ts-node": "^10.9.1",
    "tsconfig-paths": "4.1.0",
    "typescript": "^4.8.2"
  },

Node.js version

18.8.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

/Users/dmitrii/WebstormProjects/nestjs-d3/dist/app.service.js:11
const d3 = require("d3");

Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/dmitrii/WebstormProjects/nestjs-d3/node_modules/d3/src/index.js from /Users/dmitrii/WebstormProjects/nestjs-d3/dist/app.service.js not supported.
Instead change the require of index.js in /Users/dmitrii/WebstormProjects/nestjs-d3/dist/app.service.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/Users/dmitrii/WebstormProjects/nestjs-d3/dist/app.service.js:11:12)
    at Object.<anonymous> (/Users/dmitrii/WebstormProjects/nestjs-d3/dist/app.controller.js:14:23)
    at Object.<anonymous> (/Users/dmitrii/WebstormProjects/nestjs-d3/dist/app.module.js:11:26)
    at Object.<anonymous> (/Users/dmitrii/WebstormProjects/nestjs-d3/dist/main.js:4:22)

[jmcdo29]

#8736

[yf-hk]

Why it's closed and locked. We really need this feature, please...

[jmcdo29]

Because it's a major effort, that we're assessing, and there's workarounds in that thread

[JonDum]

Sorry if my tone isn't rosy here, but, man, this is incredibly frustrating. 😢

I've lost about 8 hours on separate occasions looking for workarounds to this, endless fiddling with tsconfig.json (my favorite use of my Saturday), trying to use tsx instead of ts-node (which works, but then breaks Nest's decorator metadata), trying to create shims, rewrite parts of d3, monkey patching things, all to no avail. Been a couple years since D3 went esm only and it still doesn't work with nest.

What happens when more and more libraries start going ESM only? More and more time spent fighting the framework than delivering value, I'd wager.

I was really hoping to use nest on my team's next major project because of the devtools and enterprise features, but now I'm not so sure.

[jmcdo29]

Again, there are workarounds in the linked thread about how you can use esm packages in commonjs. I understand it's less than ideal, but it is possible. With express and fastify still being commonjs packages, not to mention all the microservice packages and websockets packages, there's too many underlying issues for Nest to directly transfer to ESM, to my understanding. I do plan on continuing to look into this, but people, please stop blaming the framework when we've been trying to provide ways to work around it.