Hello from the new maintainer 馃憢
pbkit is a useful invention, but it was dying due to a lack of interest. I've been hoping someone would replace it, but no good protobuf tooling has emerged.
As a sensible parser with rich syntactic information, pbkit is still in the lead 馃く
Eventually, I had to use pbkit again, so I asked permission to maintain it. Here, I start by setting new goals for pbkit's long-term sustainability.
1. Package structures
pbkit is literally for the protocol buffers.
We've been interested in various topics that can be with the protobuf. But we can't sustain all that.
I will change the package configuration to focus on the quality of core utilities that require tier 1 support.
pbkit/core (schema, shared etc)pbkit/parserpbkit/codecpbkit/lsp (private)pbkit/cli (private, bin)
And others stay in a separate repository. In the maintenance mode, until we find each maintainer
- pollapo
- Anything related to wrp
2. Node.js compatibility
With Deno 2 migration, pbkit should be fully Node.js/NPM compatible. Which means it will officially have APIs for Node.js, with no adapters.
To be an eco-friendly package, it will require Node.js >=23 to run ESM and TypeScript natively. (Yes, I'll do not transpile it 馃挜 )
To achieve this, the implementation of pbkit and the artifacts of pbkit codegen must use only erasable syntax.
3. Performance
I've tried a lot to use pbkit not only for tooling but also for production workloads. There are many production use cases that pbkit can support ideally, such as gRPC-HTTP runtime transcoder gateway.
However, pbkit's current encode/decode implementation is slow. It should be improved. #113
Fortunately, I'd say that my optimization skills have evolved over the past few years. So, let me test.
4. Better tooling supports
The preceding goals form the basis for better tooling support. We will revisit the most essential cases from a solid foundation.
But a few candidates:
- Well-documented core APIs
- Framework for codegen
- Better
protoc interop
Rewriting pollapo and wrp might be a good target for the dogfooding.
Hello from the new maintainer 馃憢
pbkit is a useful invention, but it was dying due to a lack of interest. I've been hoping someone would replace it, but no good protobuf tooling has emerged.
As a sensible parser with rich syntactic information, pbkit is still in the lead 馃く
Eventually, I had to use pbkit again, so I asked permission to maintain it. Here, I start by setting new goals for pbkit's long-term sustainability.
1. Package structures
pbkit is literally for the protocol buffers.
We've been interested in various topics that can be with the protobuf. But we can't sustain all that.
I will change the package configuration to focus on the quality of core utilities that require tier 1 support.
pbkit/core(schema, shared etc)pbkit/parserpbkit/codecpbkit/lsp(private)pbkit/cli(private, bin)And others stay in a separate repository. In the maintenance mode, until we find each maintainer
2. Node.js compatibility
With Deno 2 migration, pbkit should be fully Node.js/NPM compatible. Which means it will officially have APIs for Node.js, with no adapters.
To be an eco-friendly package, it will require Node.js >=23 to run ESM and TypeScript natively. (Yes, I'll do not transpile it 馃挜 )
To achieve this, the implementation of pbkit and the artifacts of pbkit codegen must use only erasable syntax.
3. Performance
I've tried a lot to use pbkit not only for tooling but also for production workloads. There are many production use cases that pbkit can support ideally, such as gRPC-HTTP runtime transcoder gateway.
However, pbkit's current encode/decode implementation is slow. It should be improved. #113
Fortunately, I'd say that my optimization skills have evolved over the past few years. So, let me test.
4. Better tooling supports
The preceding goals form the basis for better tooling support. We will revisit the most essential cases from a solid foundation.
But a few candidates:
protocinteropRewriting pollapo and wrp might be a good target for the dogfooding.