Bump dependencies in package.json

[jojomatik]

I'm currently not happy with how these pixelheads version bumps work. The release configuration in pixelheads creates a new release for each dependency upgrade (e.g. sharp) in pixelheads leading to a PR in blockcluster. As only the package-lock.json of pixelheads is updated (i.e. range is widened by dependabot) the sharp-bumps never reach blockcluster. This makes these PRs essentially worthless, nothing changes except for three numbers in package*.json. No bug fixes of dependencies will be included.

Indirect/ transitive dependency updates are not possible with dependabot or renovate. Even if they were possible, they would probably be too verbose by creating way to many pull requests for a lot of dependencies.

I have therefore done some research on best practices, what's technically possible AND what would be a desirable state of these best practices in my opinon:

Theres a great article on renovate's page explaining why they recommend pinning dependency versions in package.json - at least for modules that are not meant for the browser. This might lead to duplicate dependencies, which - according to them - should not be too big of a problem most of the time.

This article created a disuccion in commitizen/cz-conventional-changelog-default-export#4 (comment) with some strong points against pinning.

As neither dependabot nor renovate are able to update transitive dependencies (with the exception of security vulnerabilities), it seems to be the library maintainers responsibility (in this case my responsibility) to regularly update dependencies, and to propagate these to downstream projects by not only updating them in package-lock.json but also in package.json.

As pixelheads depends on sharp which - as far as i know - will not run in a browser environment anyways, the downsides of increasing the version in package.json are limited (duplicate dependencies). I don't like the idea of pinning though. If a new version of sharp is available, a user of pixelheads should be able to use it. I will stick with semver version definitions instead of dependency pinning in package.json, but I will manually change the strategy to increase instead of widen.

This also has the benefit of weakening this point in aforementioned article:

Ranges for Libraries

[...]
Even if both projects use a service like Renovate to keep their pinned dependencies up to date with the very latest versions, it's still not a good idea - there will always be times when one package has updated/released before the other one and they will be out of sync. e.g. there might be a space of 30 minutes where your package specifies foobar 1.1.0 and the other one specifies 1.1.1 and your joint downstream users end up with a duplicate.

If these two hypothetical libraries have a common dependency AND use a service such as dependabot or renovate AND use semver versions e.g. ^1.1.0 and one of them receives a bump of the common library to ^1.1.1 the joint downstream will install only version 1.1.1 as it fulfills both requirements.

Originally posted by @jojomatik in jojomatik/blockcluster#349 (comment)

[jojomatik-bot]

🎉 This issue has been resolved in version 1.0.6-beta.1 🎉

The release is available on:

• GitHub release
• npm package (@beta dist-tag)

Your semantic-release bot 📦🚀

[jojomatik-bot]

🎉 This issue has been resolved in version 1.0.6 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀