JavaScript: es6 module generation

[tbillington]

Asking because I couldn't find anything about generating es6 modules instead of closure or common via protoc (https://developers.google.com/protocol-buffers/docs/reference/javascript-generated#package).

Is it possible or on the roadmap?

[lfmunoz]

Yes it isn't specified anywhere what would be the correct syntax. My guess is this: protoc --js_out=import_style=es6,binary:${DEST} -I ${SRC} ${PROTO_FILE}

but the code generated isn't showing any imports or exports so it must not be working. Can someone confirm what the correct syntax is?

[jwall149]

My version is

$ protoc --version
libprotoc 3.5.0

It doesn't even complain if any random import_stype provide: protoc --js_out=import_style=random,binary:${DEST} -I ${SRC} ${PROTO_FILE}

[xfxyjwf]

es6 module isn't supported yet.

[juanjoDiaz]

Any chance of ES6 imports happening soon?

Currently blocking https://github.com/grpc/grpc-web/issues/237

[sikmike]

Are there any news about ES6 support? I am trying to use grpc-web with commonjs in Vue.js, but get an error.

[thesayyn]

You should consider using https://github.com/thesayyn/protoc-gen-ts. It generates classes ES6 compatible.

[seishun]

Would you accept ES6 support in a pull request?

[Asher-]

Why is it considered to be in any way acceptable to still be relying on ES5 code 5 years after its deprecation?

[ppeou]

Please enhance protoc compiler to generate es6 modules.

[gunters63]

I made a patch for an older commit of protobuf for creating ES6 compatible code. It works fine for me, although it is far from being good enough for a pull request:

https://github.com/protobufjs/protobuf.js/issues/1567

[dibenede]

This is a reasonable request, but not planned.

[smnbbrv]

This is very disappointing. Some libraries already reject to support non-module projects and you don't plan to support modules 👍

Such a good idea of protobuf / grpc(-web) and such a poor implementation and maintenance that people who just want to use it need to use third party libs. Non-tree-shakable, builder pattern in javascript (what???), no typescript / Promises / rxjs support, no alignment to the modern technologies and the outside world (actually this issue prevents any project with "type": "module" from using protobuf) and a lack, if not missing, normal, human-readable documentation at one place. I really love protobuf and grpc, and I'm also an author of third-party plugin (actually for Angular, which should be supported by Google and not by me) and many workarounds, but I'm so tired of all the problems I need to face to just be able to use it, that I really think on quitting. All this outweights all the pros that protobuf gives.

The following is maybe not that kind, but that's what I feel. The current state of JS support just looks like a stub that's done for only one reason: to write "we support all the languages" or "here is the implementation, if you don't want to use it it's your problem". If you want your technology to stay alive you should probably reconsider what you are doing and at the very first target all the issues above and finally get away of the stone age. Every project has problems, every framework has issues, but at least they should be targeted and there should be a clear future.

[gunters63]

I can highly recommend https://github.com/timostamm/protobuf-ts as an alternative code generator. Works great in my 100% Typescript codebase. It even still uses protoc.exe under the hood.

[gonzojive]

What would be the expected output for ES6 module-style imports? It doesn't seem too hard to modify the generator C++ to support this once the desired behavior is fully specified.

---

Perhaps the following is a bit of an aside - I'm not too familiar with Typescript imports: What makes sense to me is that a generated .js (and .d.ts) file for a proto would have a canonical "import path" to use when importing it. This would make it easy to generate the imports for dependencies, and it would also make it easier to determine how to import a proto type from user code. However, associating a module with a canonical, absolute import path seems like a big pain in JS/JS based on casual Googling around 1, 2.

[smnbbrv]

Actually all imports should be done with native JS imports and to support "type": "module" it should also include the file extension, for both typescript and JavaScript it should be '.js'. This should also be adapted in well-known-types which actually made it impossible for me to proceed with patching the protoc's original output, cause changing the well-known-types in the lib was already too much (and if I remember it right they are provided by direct file reference, that's why they aren't processed properly by node.js that would normally see that the library's type is not module and gracefully treat it as it does with legacy libs).

---

Offtopic: Wouldn't it be better to make a separate generator for JavaScript like the guys already did with Golang? Extending C++ compiler is not something one expects while generating JS. This would give a chance to generate a modern tree-shakeable code with direct typescript support

[Asher-]

All imports should be done with native ES6 "import" statements. Code should not require a loader to load. That's just poor form.

[safanaj]

what about this super tiny patch? https://github.com/protocolbuffers/protobuf-javascript/pull/150/files , what do you think?

[gonzojive]

https://github.com/protocolbuffers/protobuf-javascript/pull/156/files is pretty close to completing this but needs testing and support for the built-in well-known-types.