[Bug?]: Error [ERR_REQUIRE_ESM]: require() of ES Module string-width/index.js

[Sitting-Duck351]

Self-service

• I'd be willing to implement a fix

Describe the bug

Everything was working with string-width v3.2.3, until v5.0.1 was added to yarn.lock, after then I get:

• Error [ERR_REQUIRE_ESM]: require() of ES Module <path>/node_modules/string-width/index.js

As workaround I use NPM, which adds the name to v4.2.3 and then yarn import to generate yarn.lock, since my pipeline is all based in yarn. Or if I add name string-width to v4.2.3 manually then it works.

This issue is already reported in storybookjs github:
[https://github.com/storybookjs/storybook/issues/22431]

To reproduce

Having string-width v4.2.3 and v5.0.1 in yarn.lock, run yarn --pure-lockfile

"string-width-cjs@npm:string-width@^4.2.0", "string-width@^1.0.2 || 2 || 3 || 4", string-width@^4.0.0, string-width@^4.1.0, string-width@^4.2.0, string-width@^4.2.2, string-width@^4.2.3:
version "4.2.3"
resolved "https://registry.yarnpkg.com/string-width/-/string-width-4.2.3.tgz#269c7117d27b05ad2e536830a8ec895ef9c6d010"
integrity sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==
dependencies:
emoji-regex "^8.0.0"
is-fullwidth-code-point "^3.0.0"
strip-ansi "^6.0.1"

string-width@^5.0.1, string-width@^5.1.2:
version "5.1.2"
resolved "https://registry.yarnpkg.com/string-width/-/string-width-5.1.2.tgz#14f8daec6d81e7221d2a357e668cab73bdbca794"
integrity sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==
dependencies:
eastasianwidth "^0.2.0"
emoji-regex "^9.2.2"
strip-ansi "^7.0.1"

Environment

Node: 16.14.0
Yarn: 1.22.19
Npm: 8.5.0

Additional context

No response

[liemlylac]

I have an issue like this when does not have yarn.lock and node_modules/, first yarn install and everything looks fine.

But when I add a dependency Error [ERR_REQUIRE_ESM]: require() of ES Module /node_modules/string-width/index.js occurs.

The framework I used: is NestJS version ^10.0.0
Dependencies:

{
  ..
  "dependencies": {
    "@nestjs/axios": "^3.0.0",
    "@nestjs/cache-manager": "^2.1.0",
    "@nestjs/common": "^10.0.0",
    "@nestjs/config": "^3.1.1",
    "@nestjs/core": "^10.0.0",
    "@nestjs/jwt": "^10.1.1",
    "@nestjs/microservices": "^10.2.6",
    "@nestjs/platform-express": "^10.0.0",
    "@nestjs/swagger": "^7.1.12",
    "@nestjs/typeorm": "^10.0.0",
    "axios": "^1.5.1",
    "cache-manager": "^3.4.4",
    "cache-manager-redis-store": "^2.0.0",
    "cheerio": "^1.0.0-rc.12",
    "class-transformer": "^0.5.1",
    "class-validator": "^0.14.0",
    "ioredis": "^5.3.2",
    "markdown-it": "^13.0.2",
    "matrix-bot-sdk": "^0.6.6",
    "matrix-js-sdk": "^19.5.0",
    "pg": "^8.11.3",
    "redis": "^4.6.10",
    "reflect-metadata": "^0.1.13",
    "rimraf": "^5.0.5",
    "rxjs": "^7.8.1",
    "swagger-ui-express": "^5.0.0",
    "typeorm": "^0.3.17"
  },
  "devDependencies": {
    "@nestjs/cli": "^10.0.0",
    "@nestjs/schematics": "^10.0.0",
    "@nestjs/testing": "^10.0.0",
    "@types/cache-manager": "^4.0.3",
    "@types/express": "^4.17.17",
    "@types/jest": "^29.5.2",
    "@types/markdown-it": "^13.0.1",
    "@types/multer": "^1.4.7",
    "@types/node": "^20.3.1",
    "@types/supertest": "^2.0.12",
    "@typescript-eslint/eslint-plugin": "^6.0.0",
    "@typescript-eslint/parser": "^6.0.0",
    "eslint": "^8.42.0",
    "eslint-config-prettier": "^9.0.0",
    "eslint-plugin-prettier": "^5.0.0",
    "jest": "^29.5.0",
    "prettier": "^3.0.0",
    "source-map-support": "^0.5.21",
    "supertest": "^6.3.3",
    "ts-jest": "^29.1.0",
    "ts-loader": "^9.4.3",
    "ts-node": "^10.9.1",
    "tsconfig-paths": "^4.2.0",
    "typescript": "^5.1.3"
  },
  ..
}

My tsconfig.json

{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "ES2021",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true,
    "skipLibCheck": true,
    "strictNullChecks": false,
    "noImplicitAny": false,
    "strictBindCallApply": false,
    "forceConsistentCasingInFileNames": false,
    "noFallthroughCasesInSwitch": false
  }
}

Environment:

MacOS: 13.3.1
Node: 16.20.1
Yarn: 1.22.19

[niyodusengaclement]

I had the same issue when I was running NestJS project with docker and I was able to solve it by deleting the yarn.lock file and never copy it in the app directory in Dockfile.

Here is the example of the line I removed in the Dockfile

COPY --chown=node:node yarn.lock ./

[itzsrikanth]

I had the same issue while setting up a TS library with jest and as @niyodusengaclement mentioned, deleting yarn.lock helped.

[johannesschobel]

but this i completely against the idea from the yarn.lock file. There has to be another solution for this issue.. stumbling upon the same here..

[pavelee]

Here the similar problem when executing tests with

yarn test

we can fix the problem locally by running:

yarn upgrade

But still the problem exists on our CI/CD machine 😳, we could add yarn upgrade on CI/CD machine or remove yarn.lock but it's not really good practice.

Current workaround add to your dependencies jest-cli (not --dev, it's not working)

yarn add jest-cli

Waiting for the fix 🙏

We are using the latest version of yarn

[rrd108]

I bumped into the same error today. Deleing the lock file fixed it

[Victor-Lindh]

Having the same error as well!

[craftycram]

same here when trying to install cypress

[ForeverYoung1208]

I have the same error on CI workflow. Deleting yarn.lock isn't a solution. Help please.

[KaneTesta]

Hey all!
I also faced this issue today and tried all of the above. However, adding the following to my package.json worked for me.

"resolutions": {
    "string-width": "4.2.3"
}

[oxa-klesti]

@KaneTesta , and what did you use after that, yarn add -D cypress?

[Super-Kenil]

I am currently using yarn v1.22.21. And I too am facing the same Error as OP, in my Angular v17 project

[mustafamilyas]

I've also encountered this issue when running Jest by following the Next.js Jest installation documentation. Removing the lock file fixed the issue temporarily, but it came back again after some time.

[alienriquebm]

Same error here

[dominikgebhardt]

Same error here, we are using graphql-codegen. Problem with string-width package is already described here:

dotansimha/graphql-code-generator-community#225

Also hoping for a fix 🙏

[im6]

I am not sure if this is fixed today, but i saw this error too during running jest.
I have no option but to delete lock file

[sethtomy]

I got the same error today with yarn 1.22.22. It seemed to happen after installing an Open API Generator typescript axios client. Regenerating the lock file fixed the issue.

[neaumusic]

Ok so it took a while to even wrap my head around what was happening. For me, there was a preliminary warning when using yarn 1.x.x that two versions were attempted to be installed at the same location, and that it could lead to non-deterministic behavior.

My first fix was to set resolutions for the indirect libs like this (which works but isn't optimal), and led me down what I think is the right path.

  "resolutions": {
    "string-width": "^4.2.0",
    "wrap-ansi": "^7.0.0"
  }

I then found a thread here sindresorhus/string-width#51 where someone mentioned that upgrading yarn fixed the problem. This aligns with what Claude was telling me, that it has to do with my the way my consuming package is resolving packages. That fix (for me after recently pinning both packages with https://volta.sh to node@18) is:

volta install yarn ← upgrades yarn to the latest compatible version with node

Subsequently, adding and removing my other package no longer causes the ERR_REQUIRE_ESM issue, which I think stemmed from the fact that a minor version change was specified in these libs when they should have been major changes since yarn 1.x.x resolved them incorrectly and their namespace/versions collided in the filesystem with the older minor version, though require/import interface was expected to be different between versions. Pretty much that yarn 1.x.x incorrectly resolved them in the local filesystem.

My understanding (which could be wrong) is that, during incorrect yarn resolution / collision of libs in a filesystem directory, a version on the file system resulted in an unexpected interface for require/import. Since they were still valid after removing the package based on ranges like ^4.x.x, the issue persisted because as far as yarn could tell, it was the correct package (it was not)

[zen2see]

Deleting yarn.lock, having "type": "module" in compiler options of package.json, having .cjs for jest.confg extension (jest.config.cjs) and jest.setup.js.

[zen2see]

I was able to delete yarn.lock, rename config file to jest.config.ts, rename setup file to jest.setup.ts, rerun yarn and successfully test.