-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate ES6-style code (classes, exports, imports) #156
base: main
Are you sure you want to change the base?
Conversation
…rated code. The introduction of this type changes the signatures of many generator methods that need to know how to print a JavaScript expression that refers to a given proto message or enum.
…rocessors. The import paths for proto imports don't work with our bazel rules, so we post-process the protobuf-javascript generator's output to rewrite the imports. This is easier if each import has a comment indicating the corresponding proto file.
Before this, the parent type would be returned. Now, <parent type>.<child type> is returned.
This is awesome! |
Enable compilation of protos which use the `extend` keyword. A gRPC-web service broke es6 compilation due to importing [`longrunning/operations.proto`](https://github.com/googleapis/googleapis/blob/master/google/longrunning/operations.proto), which uses annotations, which use extensions. Testing of this is being done in `rules_ts_proto` repo: [PR#9](https://github.com/gonzojive/rules_ts_proto/pull/9/files)
Any update? |
The branch works and has been updated with many fixes. We use it in web apps at work. However, last I checked, it will not be accepted upstream because the change is so large. |
Shameless plug, you might be interested in checking out protobuf-es: https://github.com/bufbuild/protobuf-es It fully supports TypeScript and ESM and is completely conformant and compatible with the Protobuf format. |
Fixes compilation using bzlmod and makes bzlmod the default.
Guys, can you make this thing moving forward? I would really like to have ESM module instead of CJS modules. |
In my fork I have been maintaining and improving the ES6 support. I don't
think the maintainers of the main repo have enough time to review the
change and get it into shape to submit.
…On Tue, Aug 27, 2024, 8:23 AM Stanislav Berkov ***@***.***> wrote:
Guys, can you make this thing moving forward? I would really like to have
ESM module instead of CJS modules.
—
Reply to this email directly, view it on GitHub
<#156 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUO5Y4AHQE6IAGDHZTMBDZTSKVTAVCNFSM6AAAAAAST6WIB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSHA3DMOBRGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Checked with `python3 tools/bcr_validation.py --check=protobuf_javascript_esm`. The module in question is my fork of the protobuf-javascript repo. The changes in the fork are unlikely to be accepted upstream (see protocolbuffers/protobuf-javascript#156).
Checked with `python3 tools/bcr_validation.py --check=protobuf_javascript_esm`. The module in question is my fork of the protobuf-javascript repo. The changes in the fork are unlikely to be accepted upstream (see protocolbuffers/protobuf-javascript#156).
There is a long-standing request for ES6 module generation: #75. This PR mostly adds such support, though it needs to be cleaned up, fixed and tested.
The code generator should still produce the same output for previously supported inputs. The es6 option changes the output style significantly.