The jupyterlab extension for Jupytext is subject to (too) many security issues

[mwouts]

Too often I get alerts about the jupyterlab extension being subject to security issues because of its dependencies.

In the recent period I have seen #904, #925, #935 and #939.

Until recently I could fix these issues by removing and regenerating the yarn.lock file.

The problems with this approach are that

1. I don't really see why the JupyterLab extension for Jupytext, which is faily simple, should depend on pinned versions of the other libraries, especially if that creates security issues
2. At the moment it does not work any more. When I do

```bash
# Go to the extension folder
cd packages/labextension

# Cleanup
rm -rf lib node_modules yarn.lock

# Install JupyterLab's plugin manager
jlpm install

# Package the extension
npm pack

# Test the extension locally
jupyter labextension install jupyterlab-jupytext-xxx.tgz

# Publish the package on npm with
npm publish --access=public

as documented in the extension's README, then I get this error:

ValueError: Extensions require a devDependency on @jupyterlab/builder@^4.0.0-alpha.1, you have a dependency on ^3.0.0
See the log file for details:  /tmp/jupyterlab-debug-v7j0xou7.log

@fcollonval , do you have recommendations on this? Do I really need to include the yarn.lock file (can't the dependencies be computed at install time?)

[fcollonval]

Hey @mwouts

There are multiple elements at play here.

First of all, as officially documented by yarn, the reason behind the yarn.lock file is:

In order to get consistent installs across machines, Yarn needs more information than the dependencies you configure in your package.json. Yarn needs to store exactly which versions of each dependency were installed.

This is developer feature to ensure any contributors have the same installed stack when developing avoiding the infamous it does not work on my computer error.

As in your case, you don't have explicit dependencies other than JupyterLab - you should be able to merge the PR from the bot without any breakage and without a need to publish Jupytext right after as this does not impact the Javascript assets you are publishing.

ValueError: Extensions require a devDependency on @jupyterlab/builder@^4.0.0-alpha.1

I guess you were using JupyterLab alpha when running jupyter labextension command. Hence the error as your extension is targeting JupyterLab v3

Note: you may envisage stopping publishing the extension on npm as the JavaScript assets are now part of the Python package.

Do I really need to include the yarn.lock file (can't the dependencies be computed at install time?)

I would advice against it. I would rather limit or stop the dependabot analysis.

[mwouts]

As in your case, you don't have explicit dependencies other than JupyterLab - you should be able to merge the PR from the bot without any breakage and without a need to publish Jupytext right after as this does not impact the Javascript assets you are publishing.

Oh that is interesting! Do I understand correctly that the yarn.lock file has no impact on the library being published, so the security issues are a concern only for the developers, not for the end users of the extension? Oh yes if so then I am happy to take the dependabot's PR - my concern with those was that I wanted to keep the changelog up to date, and also I though I had to release a new version after each PR.

I guess you were using JupyterLab alpha

Oh you're right. With jupyterlab==3.3.2 the regeneration of the yarn.lock file just worked.

Note: you may envisage stopping publishing the extension on npm as the JavaScript assets are now part of the Python package.

I agree ! Especially if the JS assets don't change as seems to be the case here !

[fcollonval]

Do I understand correctly that the yarn.lock file has no impact on the library being published, so the security issues are a concern only for the developers, not for the end users of the extension?

Generally speaking, it may concern your end users if the code you are publishing has the security vulnerability - for example if you were shipping lodash within Jupytext as a direct dependency not provided by JupyterLab. If the bot update lodash, you should release a new version with the security update.

But in your case, there are only 4 direct dependencies that are all JupyterLab packages. So your JavaScript assets do not contain third-party libraries. And therefore the vulnerabilities patches to be published for the end users are the concern of JupyterLab maintainers and not yours directly.