Our CVE scanner reports several vulnerabilities in the jupyterlab package. The findings are all contained in the tests or staging directory inside the package.
When evaluating a Jupyter application with these methods, you have to ask whether the security posture you are seeking is even possible when you are asking users to execute arbitrary code in nearly any language, and giving them the ability, by default, to install any package. Even removing some of the useful features which make this easy for a trusted user will not make them hard for a semi-motivated bad actor or their script.
Anyhow:
removing tests is probably fine, and indeed, this should be done upstream (along with some other packaging issues).
removing staging will break the user application, and likely nothing at all will work, which would be very secure indeed.
the specific mermaid finding is a red herring as jupyterlab ships its own version of dompurify.
In addition, these dependencies are not used on runtime but only present this for extension development or similar. I recognise that this is difficult for users of automatic scanners to know which dependencies do what and I opened:
From a quick look - only considering the ones in staging:
body-parser, path-to-regexp and semver (in versions 7.5.0 and 7.5.1) - used by verdaccio or its dependencies which are only used for testing
ip is used by dependencies of node-gyp which would not be used except for extension and core developers or admins using source installation of extensions (users are recommended to only install prebuilt extensions)
cross-spawn is used by yarn and dependencies of eslint-plugin-prettier again this is only used by developers using jlpm command