Troubling notices on socket.dev

[CodeWithOz]

Some troubling notices for this package on socket.dev. Worth investigating because high scores and no (or lightly severe) notices make it easier to push for adoption of this package.

[jasonsantoleo]

This looks like a really important challenge for danfojs-node's security and adoption
i am a student who want to contribute to open source, and I'd love to take a shot at investigating and fixing these Socket.dev notices. Is it okay if I start looking into this?

[risenW]

@jasonsantoleo sure, go for it.

[jasonsantoleo]

Hi RisenW,
Subject: My understanding of socket.io dependency health for Danfo.js
Following up on our chat, I did some research on the socket.dev notices for Danfo.js—it’s really interesting
Here are my thoughts:

1. General Dependency Clean-Up
   What I saw:
A bunch of small, older packages (like es-define-property, function-bind, etc.). The scanner suggests these could be updated for better code health and compatibility.
   My thoughts:
This seems like a good, feasible fix. We can use npm override to point to the recommended versions with low risk.

2. Deprecated Packages
   What I saw:
Some packages are marked as officially deprecated (e.g., glob, npmlog, rimraf, uuid). This is a bit more serious, especially since deprecated packages won’t receive future updates—particularly security patches.
   My thoughts:
Updating to a newer, actively maintained version is a better long-term solution. For most of them, it should work fine.
   One problem:
The request package is not only deprecated but also has known security vulnerabilities like SSRF. Since it's completely unmaintained, the best fix would be to swap it out for a modern library like axios. But this might require a bigger change.

3. Deep Dependencies (like TensorFlow)
   What I saw:
tfjs-node (and a few others like core-js, ajv, detect-libc) got flagged for things like using eval, network access, native code, install scripts, and shell access.
   My thoughts:
After looking into it, this is just how tfjs-node is designed to work—to support native TensorFlow code, download models, and offer performance benefits. Trying to “fix” these would likely break the library. So, I think the best approach is to understand why these flags are there and document that this is expected behavior.
   One exception:
The ajv package was flagged for using eval. It might be possible to fix this by updating ajv to a newer version.

4. Trivial Package
   What I saw:
A tiny package called set-blocking (just 7 lines of code).
   My thoughts:
If Danfo.js directly uses this code, we could just copy those 7 lines directly into the danfojs-node code and remove the dependency entirely.

These are my thoughts so far. Before making any changes, I’d really appreciate your input on how to work through these issues.

• Which of these issues would you consider the highest priority for me to tackle first?
• Specifically for the deprecated packages, would you like me to try updating them and see if any breaking changes occur, or should I hold off for now?
• And for request, does the idea of migrating to node-fetch or axios sound like the right path—even if it’s a bigger task?
  This is a heavy task for a newbie like me 😅, so your guidance would really mean a lot
  Thanks again