[BUG] Outdated dependencies causing deprecation warnings in Jenkins build (Node.js 24 + npm 11)

[Ramya2801]

🐛 Bug Report

ExcelJS 4.4.0 depends on deprecated packages that produce warnings during npm ci / npm install, creating noise in CI/CD pipelines and flagging in security review processes.

Lib version: 4.4.0 (latest as of 5 May 2026)

Steps To Reproduce

// package.json
{ "dependencies": { "exceljs": "^4.4.0" } }

# Install with Node 24 + npm 11
npm ci

Output

npm warn deprecated rimraf@2.7.1: Rimraf versions prior to v4 are no longer supported
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it.
npm warn deprecated glob@7.2.3: Old versions of glob are not supported, and contain widely publicized security vulnerabilities
npm warn deprecated fstream@1.0.12: This package is no longer supported.
npm warn deprecated glob@10.5.0: Old versions of glob are not supported

Dependency chain

exceljs@4.4.0
├── archiver@5.3.2
│   └── glob@7.2.3
│       └── inflight@1.0.6
├── rimraf@2.7.1
│   └── glob@7.2.3 (duplicate)
└── unzipper@0.10.14
    └── fstream@1.0.12

The expected behaviour:

npm ci should complete without deprecation warnings from transitive dependencies. All internal dependencies should use actively maintained packages.

[gameroman]

Try one of these which are more actively maintained forks

https://github.com/excel-js/exceljs

https://github.com/cjnoname/excelts

https://github.com/protobi/exceljs

[uriah-chs]

Is anybody actively maintaining fork that is published to npm?

[gameroman]

Is anybody actively maintaining fork that is published to npm?

@uriah-chs see the comment above you

[protobi-pieter]

I believe exceljs is not actively maintained.

we actively maintain https://github.com/protobi/exceljs for our use, and it is a close descendent of excel-js/exceljs with many bug/security fixes.

https://github.com/cjnoname/excelts is a more radical fork -- all the js code was transpiled into typescript, and has been extensively extended with new features.

[uriah-chs]

It seems the temporary fork might be permanent? :) And "we" in this case is protobi? This seems like maybe our best path forward.

The website listed on your GH profile "http://www.protobi.com/" seems to throwing Internal Server error sporadically when I was trying to hit it just FYI. Could have been cold start? seems to be working now anyway.

[gameroman]

You can also see a comparison on https://npmx.dev/compare?packages=exceljs,@cj-tech-master/excelts,@excel.js/exceljs,@protobi/exceljs

[uriah-chs]

@protobi-pieter , were you aware that your package still had the uuid vuln?

[gameroman]

@protobi-pieter , were you aware that your package still had the uuid vuln?

I opened protobi#81 but that will require a new major version

[protobi-pieter]

@uriah-chs What is the concern, is it more than npm audit shows a notice?

There is essentially no practical attack vector — for anyone, not just exceljs. And the vulnerable code path is unreachable through Exceljs's API.

The reported issue affects only uuid v3/v5/v6 (not v4) and even then you'd need to pass certain arguments that we don't pass. And even the "exploit" is just silently get a truncated/garbage UUID instead of a thrown error.

ExcelJS uses only uuidv4() with no arguments :

{${uuidv4()}}.toUpperCase()

• Uses v4 (not v3/v5/v6)
• No buf parameter
• No offset parameter
• No attacker-controlled input near the call

[uriah-chs]

a different third party vulnerability scanner, but yes. just want a clean bill of health if possible. getting a security exception is extra work.