javascriptdata
Troubling notices on socket.dev
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.
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?
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:
-
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.
-
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.
-
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.
-
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