For starters, the author seems surprised that the API changed between versions 0.4.0 and 0.16.0 (“it is not a major version or anything”); but in my mind any change from 0.x to 0.y is a major version change (semver.org is even less restrictive on this point, saying that there is no guarantee of a stable API in any 0.x.y version).
The author then goes on to patch the library to change its behavior, which seems like it will make further dependency bumps that much harder (now you have to not just understand the API, but the implementation, so you can patch it!). This seems to be done in service of having the new version produce the same token as the old one; but the post goes on to describe the actions required to validate an old token with a new library:
make sure the verify_with_key call type permits Option<String> as a value in its BTreeMap; and
ensure the token is web-safe base64 encoded by doing .replace('+', "-").replace('/', "_")
Indeed, making those changes permits validation of the older-style token, without changes to the upstream library.
When you need dozens of dependencies even for simple things and your code rots within a few months due to API changes of said dependencies, by choosing Rust you truly build your house on sand.
edit: I’ve just noticed that the 0.4.0 version of jwt was from 2016, so it’s upgrading 6 years worth of development. That’s almost entire lifetime of post-1.0 Rust. Changing a couple lines of code per 6 years of a nominally experimental and unstable library is really not that bad. The old dependency worked for twice as long as Debian stable release cycle.
This post surprised me in several places.
For starters, the author seems surprised that the API changed between versions 0.4.0 and 0.16.0 (“it is not a major version or anything”); but in my mind any change from 0.x to 0.y is a major version change (semver.org is even less restrictive on this point, saying that there is no guarantee of a stable API in any 0.x.y version).
The author then goes on to patch the library to change its behavior, which seems like it will make further dependency bumps that much harder (now you have to not just understand the API, but the implementation, so you can patch it!). This seems to be done in service of having the new version produce the same token as the old one; but the post goes on to describe the actions required to validate an old token with a new library:
verify_with_keycall type permitsOption<String>as a value in itsBTreeMap; and.replace('+', "-").replace('/', "_")Indeed, making those changes permits validation of the older-style token, without changes to the upstream library.
When you need dozens of dependencies even for simple things and your code rots within a few months due to API changes of said dependencies, by choosing Rust you truly build your house on sand.
edit: I’ve just noticed that the 0.4.0 version of jwt was from 2016, so it’s upgrading 6 years worth of development. That’s almost entire lifetime of post-1.0 Rust. Changing a couple lines of code per 6 years of a nominally experimental and unstable library is really not that bad. The old dependency worked for twice as long as Debian stable release cycle.
JWT is not a simple thing.