Doc project dependency issues #277

Activity

1. TonyGravagno

   added sub-issues on Jun 14, 2025

   • body-parser dependency issue #278
   • brace-expansion dependency issue #279
   • cookie dependency issue #280
   • cross-spawn dependency issue #281
   • path-to-regexp dependency issue #282
   • prismjs dependency issue #283
   • send dependency issue #284
2. alex-Symbroson commented on Jun 17, 2025

   

   alex-Symbroson

   on Jun 17, 2025

   Collaborator

   More actions

   Dependency issues may be fixed if upgrading the library doesn't result in undesired/broken behaviour when generaring the docs.

   This means:

   • dependency conflicts should be avoided
   • runtime errors during generation should be avoided
     • any error may be investigated to check if a simple fix is available
   • changes to the generated html docs with unchanged js/json input should be avoided
     • any change has to be reviewed very carefully by inspecting their html diff and rendered webpage
3. TonyGravagno commented on Jun 18, 2025

   

   TonyGravagno

   on Jun 18, 2025

   CollaboratorAuthor

   More actions

   @alex-Symbroson for all of the reasons you cited, I created individual tickets to process each dependency separately.

   If this were a single ticket and we were noobs, we would just force a "fix" ... and then spend a lot of time trying to fix what just got broke - which is exactly what you warn against. 😁

   So I created this as a catch-all ticket that can be closed after each individual dependency has been considered and processed to its own unique completion.

   Someone needs to be assigned to check any of the sub-tasks.
   This isn't easy, I'm just surfacing the issue.

   Thanks.
4. alex-Symbroson commented on Jun 18, 2025

   

   alex-Symbroson

   on Jun 18, 2025

   Collaborator

   More actions

   it may be sifficient to just run npm audit --fix to apply all at once and see what happens. If everything still works as expected its all good

   Another thought on this - having these vulnerabilities might even be irrelevant as none of these are exposed to any attackable service of any kind. It is loterally just a local cli tool that is ran for a few seconds with purely local user input. The generated html is the only thing that will be shipped to users and served online. So this is the only thing that could be monitored for security - but this won't be reported by npm or any other service. There are far more concerning security aspects of DS - i.e. serving the Web IDE over http that also allows arbitrary code execution.
5. TonyGravagno commented on Jun 27, 2025

   

   TonyGravagno

   on Jun 27, 2025

   CollaboratorAuthor

   More actions

   I actually agree with you. It can't hurt to try the fix option - and I did - and it all looks OK.

   I took it a step further and updated all sub-dependencies - no changes to package.json or primary deps/devDeps.

   Please check PR.
6. TonyGravagno

   added

   pr pending

   on Jun 27, 2025