How to resolve Dependabot alerts

This repository relies on Github's Dependabot for automatic security scanning for frontend dependencies. Since resolving these alerts is not trivial, here's a general guideline on how to address them.

1. Check if the alert is relevant to us

Run yarn audit-production-dependencies and check whether the alert stems from a production dependency or a development one. Dependabot has a long-running issue that dev dependencies can't be ignored, ideally this step would be automatic.

If the alert stems from a development dependency, generally no immediate action is required, unless the alert is an extreme case such as malicious code being included in the dependency or similar. Most Dependabot alerts for development tools are benign, as they're often things such as self-DoS via incorrect configuration. Check the alert and if it isn't applicable to us, dismiss it. In this case, no further action is necessary and you're done.

If the alert stems from a production dependency, it needs to be addressed.

2. Check if the affected dependency is a direct dependency

Usually packages have a fixed version available by the time Dependabot flags the issue. If the package is a direct dependency, e.g. something we define in package.json, in the ideal case we can update that single package, check any code that relies on it for breaking changes, test it, and push out the fix.

If no update is available, evaluate urgency. If the vulnerability is applicable but not urgent, create a ticket and periodically revisit to see if an update is available. If the vulnerability is applicable and urgent, evaluate on a case-by-case basis. Depending on the situation, it might be easiest to help the dependency maintainers fix the issue, or to monkey-patch our use case, or to refactor the dependency out, or etc.

3. If the dependency is not a direct dependency, figure out why we have it

If the dependency is not defined in our package, it's a subdependency. Run yarn why <package name> to see which package(s) rely on it. If the dependency's parent has a fixed version available, update the parent, check code that relies on it, test it, and push out the fix.

If there's a fixed version out for the subdependency but not for the parent, you can use resolutions to force Yarn to overwrite that specific subdependency. This is equivalent to monkey-patching the parent dependency's dependency list. On the downside, this needs thorough testing and can have unexpected side effects, on the upside however, this is the least effort and maintenance work for us in the case of a happy path. If forcing resolution works, test it and push out the fix. If not, you will need to either coordinate with the parent dependency to get a fixed version out, or to refactor out the dependency.

If no update is available, see previous section about direct dependencies and no updates.

4. Port the changes

After fixing the issue for master, it's crucial to check all other branches that are currently supported to see whether the issue is applicable there as well. Port as necessary.