Dependency management guidelines

[gabrocheleau]

In order to make the security of the monorepo more robust, we've discussed establishing a set of good practices that should be followed when updating or installing dependencies.

• package.json and/or package-lock updates should be scoped separately (i.e., separate PR) from unrelated updates. If new packages are installed or updated, the rationale for these modifications should be outlined in the PR.
• Whenever a PR modifies package-lock, contributors and reviewers should run npx lockfile-lint --path package-lock.json --allowed-hosts npm --validate-https . Perhaps this could eventually be added to the CI.
• Vulnerabilities signaled by npm audit should be gone through and fixed or if not relevant, they should be documented (i.e. what they are and why they're not a concern in our case). Particular attention should be paid to non-dev dependencies (npm audit —production).
• As suggested by @paulmillr, we should move away from using dependency ranges (e.g. ^1.2.3) and only use fixed versions of packages. Before doing so, a review should be completed for duplicate versions of deps (e.g. trie uses dep abc@1.2.1, and dep xxx which depends on abc@1.2.3).

[faustbrian]

Should lockfile-lint be triggered when a change to package-lock.json is detected in a PR or on some schedule via a cronjob?

[gabrocheleau]

Yes, that's a good idea!

[faustbrian]

Which of the 2 was the yes for? 😅

• when a change to package-lock.json is detected in a PR
• on some schedule via a cronjob

[gabrocheleau]

Ah, haha, I intended to say yes to the first, didn't read past that.

[faustbrian]

#2201