feat: decode future schema versions without throwing #213
Conversation
We can now decode future schema versions without throwing. For example, if some future version encodes `Observation_2`, we can decode it as an `Observation_1`. Closes [#168]. [#168]: https://github.com/digidem/mapeo-schema/issues/168
| @@ -1,7 +1,7 @@ | |||
| { | |||
| "compilerOptions": { | |||
| "target": "es2019", | |||
| "lib": ["es2020"], | |||
| "lib": ["es2022"], | |||
There was a problem hiding this comment.
Necessary to use Object.hasOwn. Only affects type checking.
| @@ -14,12 +20,13 @@ export class ExhaustivenessError extends Error { | |||
|
|
|||
| /** | |||
| * Get the name of the type, e.g. `Observation_5` for schemaName `observation` | |||
| * and schemaVersion `1` | |||
| * and schemaVersion `5` | |||
There was a problem hiding this comment.
This change isn't strictly related but I believe it's a typo.
| '', | ||
| ...versionsLines, | ||
| '', | ||
| ...knownVersionsLines, |
There was a problem hiding this comment.
knownVersionsLines is no longer used so we can remove it, and all its dependencies.
Is this actually reasoned like this? shouldn't we be able to decode |
|
Maybe more accurate: we can decode future schema versions, even if we don't know about them yet. As you said, we won't be able to decode newer fields, but that's just how Protobuf works. |
|
Post-merge review: All looks good! As a non-urgent (and post-mvp) follow-up, maybe we can drop the schema version from being part of the protobuf name? I don't see a need for that now. But we can worry about this at a later time. |
Yeah, having the schema version as part of the protobuf is not useful but I think there was a reason for that? We should double check just in case |
We can now decode future schema versions without throwing. For example, if some future version encodes
Observation_2, we can decode it as anObservation_1.Closes #168.