Discussion: lock dependencies

[jimlambie]

We need a solution for locking dependencies in Web (and other products, of course).

We have had a couple of failed builds recently where a package developer released a dud version that was within our dependency range.

Asking for a discussion about how we go about this, whether we rationalise the semver ranges in the package.json, commit a package-lock.json to the repo or use npm shrinkwrap before releasing.

All comments welcomed!

[eduardoboucas]

I think we should start by pinning our dependencies to only allow automatic patch updates (e.g. "@purest/providers": "^1.0.0" becomes "@purest/providers": "~1.0.0"). This means we're more strict about updates to our dependencies, but flexible enough to not have to manually look for bug fixes for them.

At the same time, I think adopting a package-lock file would be a good idea, ensuring we're safe when:

• products are installed using different versions of npm
• a dependency of a dependency has a new version, which will not fall under our semver update rules described above

[jimlambie]

As @eduardoboucas has suggested ^

We'll be pinning dependencies, then committing the lock file.

[mingard]

Reopening this issue to provide a response:

I believe we should be making the decision at the point of release, so using shrinkwrap would be my preference. I've been using package-lock on some projects recently, but I don't believe we should be applying restrictions outside of the release.

With package-lock, files that are not in the top-level package are ignored, but shrinkwrap files belonging to dependencies are respected.

[jimlambie]

What do you mean by "applying restrictions outside of the release"?

[mingard]

Applying a manifest for packages outside on NPM, so on github

[jimlambie]

I absolutely believe that we should be doing that. The release and the source code obtained directly from the repository should behave in the same way for everyone. At the very least is removes the need to ask anyone who has an issue "what version of xyz has been installed?"

It's true that perhaps the package lock solution isn't ideal, and shrinkwrapping might be the way to go. The first step was to pin stricter versions of dependencies, and I believe we've done that.

[mingard]

Okay, so:

• strict version definition in package.json
• shrinkwrap for NPM

[adamkdean]

RE: @eduardoboucas "This means we're more strict about updates to our dependencies, but flexible enough to not have to manually look for bug fixes for them."

If Snyk is looking at the repos, then we should be able to at least cover ourselves from a security point of view, and update/test/release the package versions when Snyk detects an issue. And perhaps we just have a schedule were we update all deps and do the test/release etc.