The idea here is that js-multiformats is going to require a switch to using the multicodec integer code rather than string, which does away with the need to bundle the entire multicodec table (and if you want string and you're happy to have the table then that's fine but you get to choose that). Experience shows that this is the most painful compatibility problem when switching between this library and multiformats.CID (and vice versa). Having a constructor that can take (optionally) an integer code rather than a string makes it the same constructor as multiformats.CID and exposing the code property makes it the same interface. So we can write new code that works against CID and multiformats.CID without having to worry too much. The asCID() will be icing on the cake too.
As long as we're getting an awkward breaking change into the code, we may as well make sure that anyone who has that code also has this and there's not an in-between state where there's breaking code and then there's this feature out there and you may have one and not the other. Basically it'd be nice to have this out in the wild ASAP to ease future transition and the current breaking change release seems like a good mechanism to force that.
(this PR assumes #117, review should focus only on the HEAD commit please, c043bc5)
Ref: https://github.com/multiformats/js-cid/pull/117#issuecomment-668131658
The idea here is that js-multiformats is going to require a switch to using the multicodec integer code rather than string, which does away with the need to bundle the entire multicodec table (and if you want string and you're happy to have the table then that's fine but you get to choose that). Experience shows that this is the most painful compatibility problem when switching between this library and
multiformats.CID
(and vice versa). Having a constructor that can take (optionally) an integer code rather than a string makes it the same constructor asmultiformats.CID
and exposing thecode
property makes it the same interface. So we can write new code that works againstCID
andmultiformats.CID
without having to worry too much. TheasCID()
will be icing on the cake too.As long as we're getting an awkward breaking change into the code, we may as well make sure that anyone who has that code also has this and there's not an in-between state where there's breaking code and then there's this feature out there and you may have one and not the other. Basically it'd be nice to have this out in the wild ASAP to ease future transition and the current breaking change release seems like a good mechanism to force that.