feat: extensions

[davidzeng0]

Can be automatically merged

[davidzeng0]

I hope you like the way I implemented it, if you want any changes let me know.

One possible problematic area of note is that the code parses both packed and unpacked extensions, and packed is always parsed before the unpacked, leading to possible re-ordering. If I remember correctly, protobuf's website said that applications should not expect field order to be preserved, so it shouldn't be a problem.

ts-proto-decriptors should be updated to add extensions

[davidzeng0]

Any thoughts on this?

[stephenh]

Hey @davidzeng0 ; from my initial scan of the tests, it looks pretty great, very standard approach to protobuf extensions AFAIU (I've not actually used them personally before). It'll probably be the weekend before I dive in a bit more, but its great to have this feature. Thank you!

[davidzeng0]

Alright 👍

[davidzeng0]

Rebased and fixed tests

[stephenh]

This looks great!

Awhile ago I'd thought about maybe trying to figure out an alternative API to the stock Extension.set(message, someConst, value), like something like:

const message = ...
const extended = Extension.wrap(message)
extended.someField = 1
extended.otherField = 2

But I don't think that's even possible b/c the proto file doesn't even have a name for what the wrapped type would be, i.e. something like:

extension MyNiceName extends Extendable {
  string someField = 1 
}

Would let us know to use MyNiceName as the type name for all of the someField / etc. fields ... but that is just not there/something they thought to include in the proto file. 🤔 So 🤷 I think that puts a damper on any cute/alternative APIs.

[stephenh]

🎉 This PR is included in version 1.146.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release
• v1.146.0

Your semantic-release bot 📦🚀

[davidzeng0]

Thanks for being patient with me :)

[davidzeng0]

A ts-proto-descriptors bump with outputExtensions=true would be great

[davidzeng0]

ts-proto-descriptors bump: #814