I have a package.json file with the following dev-dependencies:

  "devDependencies": {
    "@nx/js": "18.0.4",
    "@nx/jest": "18.0.4",
    "@nx/eslint-plugin": "18.0.4",
    "typescript": "5.3.3",
    "eslint": "8.56.0",
    "jest": "^29.7.0",
    "@types/jest": "^29.5.12",
    "ts-jest": "29.1.2",
    "nx": "latest"
  }

When I run npm install locally, it works without displaying any errors or warnings.

When I run the same command with the same package.json file in our build environment (as a part of an Azure DevOps pipeline), it fails with the following error:

npm warn deprecated [email protected]: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.

Based on that thread on Github, it appears this is related to a transitive dependency somewhere in the intestines of Jest, and the issue has already been known for more than half a year. But then, the package.json of another repo of ours references the same Jest version, and there, the build process does not exhibit any problems.

What could be the cause and how do I fix (or even just analyze) this?

I have a package.json file with the following dev-dependencies:

  "devDependencies": {
    "@nx/js": "18.0.4",
    "@nx/jest": "18.0.4",
    "@nx/eslint-plugin": "18.0.4",
    "typescript": "5.3.3",
    "eslint": "8.56.0",
    "jest": "^29.7.0",
    "@types/jest": "^29.5.12",
    "ts-jest": "29.1.2",
    "nx": "latest"
  }

When I run npm install locally, it works without displaying any errors or warnings.

When I run the same command with the same package.json file in our build environment (as a part of an Azure DevOps pipeline), it fails with the following error:

npm warn deprecated [email protected]: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.

Based on that thread on Github, it appears this is related to a transitive dependency somewhere in the intestines of Jest, and the issue has already been known for more than half a year. But then, the package.json of another repo of ours references the same Jest version, and there, the build process does not exhibit any problems.

What could be the cause and how do I fix (or even just analyze) this?

• npm
• npm-install

1 Answer 1

First things first - this isn't an error, it's a warning. You can decide if you want to address it or can ignore it. It shouldn't break the build.

Regarding analyzing the issue - running npm ls --all will give you a tree of all the dependencies and transitive dependencies your project has:

➜  myproj npm ls --all
[email protected] /Users/mureinik/src/untracked/myproj
├─┬ @nx/[email protected]
│ ├─┬ @nrwl/[email protected]
│ │ └── @nx/[email protected] deduped
│ ├─┬ @nx/[email protected]
│ │ ├─┬ @nrwl/[email protected]
│ │ │ └── @nx/[email protected] deduped
│ │ ├─┬ [email protected]
│ │ │ └─┬ [email protected]
│ │ │   ├── [email protected]
│ │ │   ├── [email protected] deduped
│ │ │   ├─┬ [email protected]
│ │ │   │ └─┬ [email protected]
│ │ │   │   └── [email protected] deduped
│ │ │   └─┬ [email protected]
│ │ │     └─┬ [email protected]
│ │ │       ├── [email protected] deduped
│ │ │       └── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ └── [email protected] deduped
<snipped - output is VERY long

If you read through the output, you'll see that inflight is transitively required through @nx/jest.
Unfortuntely, even the latest @nx dependencies (20.4.0 at the time of writing this post) suffer from the same problem, so unless you want to change your tech-stack, I fear you're out of luck.
Having said that, inflight isn't explicitly broken - while leaking memory obviously isn't a great behavior, for a dev dependency, it might just be OK.

EDIT:
Followup - as noted in the comments, npm completes with an exit code of 0, indicating this is indeed not an error. If the warning in the output is a problem, you can suppress it by adding a --silent flag to the command:

npm install --silent

Remark by OP:

The concrete issue for the OP was that the failOnStderr option was set to true in the Azure DevOps pipeline that ran the PowerShell script. Therefore, the warning (which was printed to stderr) caused the build to fail.