fix(deps): update module github.com/multiformats/go-multiaddr to v0.15.0 #862
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v0.14.0
->v0.15.0
Release Notes
multiformats/go-multiaddr (github.com/multiformats/go-multiaddr)
v0.15.0
Compare Source
Breaking Changes
Multiaddr
interface type.[]Component
. Not an interface.len(ma) == 0
, exactly how slices should be checked withlen(s) == 0
rather thans == nil
.Multiaddr
as there is noMultiaddr
to implement. The do implement aMultiaddrer
interface that lets them convert to Multiaddrs.Multiaddr
can no longer be a key in a Map. If you want unique Multiaddrs, usestring(Multiaddr.Bytes())
orMultiaddr.String()
as the key, otherwise you can use the pointer value*Multiaddr
.Why?
This library has had multiple issues related to Multiaddr being an interface. Many methods use and return nil as the zero value, which behaves poorly when the user forgets to do a nil check on every returned value and attempts to call a method on the nil pointer. For example, using Split to split a Multiaddr and then using Join to rebuild the original Multiaddr historically would panic in case one side of the split was nil. Using an interface also leads to incorrect usages of == to check if two Multiaddrs were equal (would only work for pointer equality) and, likewise, incorrectly using Multiaddr as a key for a map.
Using an interface is typically done to provide a consistent API surface for multiple implementing types. In practice however, the Multiaddr interface was only implemented for multiaddr and component (with arguably some awkwardness when using a component as a Multiaddr).
The better approach is to use a concrete type for a Multiaddr. This lets pointer receiver methods work even if the pointer is nil, since the compiler already knows which function to call. Most methods now take a value rather than a pointer which avoids the issue of a nil pointer dereference completely.
What's changed
v0.15 refactors the codebase to make it much harder to hit nil pointer dereference panics.
It does so by taking a different approach to how we've treated multiaddrs in the past. Instead of attempting to make them a general datastructure, we focus on treating them as just an encoding scheme. Users of multiaddrs are expected to parse the multiaddr into some struct that is suitable for their use case, and use the multiaddr form when interoperating. By treating Multiaddrs as just an encoding scheme we can make a number of simplifications in the codebase. Specifically we now:
Migration
Refer to ./v015-MIGRATION.md for breaking changes and migration tips
Full Changelog: multiformats/go-multiaddr@v0.14.0...v0.15.0
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.