build(deps): bump pixelheads from 1.0.4 to 1.0.5 in /backend

[dependabot]

Bumps pixelheads from 1.0.4 to 1.0.5.

Release notes

Sourced from pixelheads's releases.

v1.0.5

1.0.5 (2022-03-15)

Dependency updates

• deps: bump sharp from 0.30.2 to 0.30.3 (8ae6fc2)

Commits

• bdc6a43 release: 1.0.5
• 8ae6fc2 build(deps): bump sharp from 0.30.2 to 0.30.3
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[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.

I will close this PR now, as it is esentially worthless. The next version bump in pixelheads should lead to a PR bumping indirect dependencies as well.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.