Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: protocolbuffers/protobuf-javascript
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: main
Choose a base ref
...
head repository: refurbed/protobuf-javascript
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: main
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 5 commits
  • 3 files changed
  • 1 contributor

Commits on Jul 2, 2026

  1. Implement ES6 import style for JS generator 

    Fills in the kImportEs6 GeneratorOptions::ImportStyle, which was
already accepted as a valid --import_style=es6 flag but had no
actual codegen behind it. Emits `import`/`export` statements instead
of goog.require()/CommonJS require(), mirroring the CommonJS-strict
code path.

Ported from refurbed/protobuf@046bb7af7, originally written by
Gunter Spranz and Duncan Mac-Vicar P. against the JS generator before
it was split out of protocolbuffers/protobuf into this repo.
    @abdusco
    abdusco committed Jul 2, 2026
    Configuration menu
    Copy the full SHA
    0dc8a7d View commit details
    Browse the repository at this point in the history

  2. Extend proto from transitively-referenced files, not just direct imports 

    commonjs_strict and es6 import styles populate a file-local `proto`
object instead of registering into a shared global, but the object
was only ever extended from this file's directly declared proto
imports (file->dependency()). Code generated elsewhere (setters,
repeated-wrapper-field helpers, oneof arrays, etc.) references
cross-file message types via their bare namespaced path (e.g.
proto.google.protobuf.Any), assuming they exist on that object --
which breaks whenever the referenced type comes from a file that's
only imported transitively (through one of this file's direct
imports) rather than directly.

Walk the file's messages/extensions to find every message type
actually referenced, and extend proto from the union of that and the
direct imports. This is the generator-level fix for two hand-patches
platform's Makefile had to carry to work around exactly this (Any
and BuybackAttribute references resolving to undefined at runtime).
    @abdusco
    abdusco committed Jul 2, 2026
    Configuration menu
    Copy the full SHA
    d3e188f View commit details
    Browse the repository at this point in the history

  3. ci: retrigger build after enabling Actions on fork

    @abdusco
    abdusco committed Jul 2, 2026
    Configuration menu
    Copy the full SHA
    f49e954 View commit details
    Browse the repository at this point in the history

  4. ci: add protoc-gen-js release asset workflow 

    Builds and packages the protoc-gen-js binary for linux-amd64 and
darwin-arm64 via bazel, gated on npm test passing, and uploads the
tarballs (+ SHA256SUMS) to a release. Triggers on release publish or
manual workflow_dispatch (existing draft release tag + source ref).

Modeled on abdusco/protobuf's build-protoc-release-assets.yml, which
runs successfully on a personal account without needing paid/large
runner tiers -- deliberately uses plain macos-14 rather than
macos-14-large (which isn't available on personal-account forks and
is unrelated to this build; upstream only uses it for build.yml's
darwin_x86_64 cross-compile matrix entry).
    @abdusco
    abdusco committed Jul 2, 2026
    Configuration menu
    Copy the full SHA
    329a51c View commit details
    Browse the repository at this point in the history

  5. Route repeated-message-field adder's ctor ref through SubmessageTypeRef 

    GenerateRepeatedMessageHelperMethods built the add<Field>() method's
constructor reference via the unconditional GetMessagePath(field's
message_type), unlike every sibling call site (getters, setters,
(de)serialization) which already go through SubmessageTypeRef to
account for commonjs_strict/es6 import styles referencing message
types via their module alias rather than the full proto.a.b.C path.

This was the actual root cause of the two hand-patches in platform's
Makefile: for a repeated message field whose type comes from another
proto file (e.g. `repeated google.protobuf.Any details`, `repeated
BuybackAttribute attributes`), addToRepeatedWrapperField's ctor arg
resolved to the bare `proto.google.protobuf.Any` / `proto.<pkg>
.BuybackAttribute` path -- which is never populated under es6/strict
styles (they only extend a flat top-level export onto the local
`proto`, not the deep namespace), so the reference was undefined at
runtime. The prior "extend from transitively-referenced files" fix
was necessary but not sufficient for these two cases, since both
imports were already direct.
    @abdusco
    abdusco committed Jul 2, 2026
    Configuration menu
    Copy the full SHA
    46ed1b5 View commit details
    Browse the repository at this point in the history
Loading