Comments (6)
That's great. I'll adapt the solution you gave to my actual repo but, once again, thank you very much!
Very insightful solution and how the plugin works.
from protobuf-es.
Leandro, could you explain a bit what you expect?
The option is documented with:
If the paths=source_relative flag is specified, the output file is placed in the same relative directory as the input file. For example, an input file protos/buzz.proto results in an output file at protos/buzz.pb.go.
This is the behavior with protoc-gen-es
out of the box. The input file protos/buzz.proto
results in protos/buzz_pb.js
.
from protobuf-es.
Hi @timostamm, thanks for the prompt response.
I've just created a small repo to show the case: https://github.com/leandro-branco/protobuf-es-example.
When I run, buf
generate, the package/acme/example/protos/api/v1/hello.proto
is created at example/protos/api/v1/hello_pb.ts
in the root folder (and not in package/acme/example/protos/api/v1/hello_pb.ts
as expected).
Creating the repo, I've realised it seems to be something related to buf
workspaces. When trying to define buf workspace with multi module, for instance, a module in example/acme
folder, buf
doesn't generate in the correct folder.
Without buf.work.yaml
, it works.
I'm also not able to config the buf.gen.yaml
to output files in a relative folder to the proto
source like:
version: v1
plugins:
- plugin: buf.build/bufbuild/es:v1.3.0
out: ./gen
opt:
- target=ts
Files are generated at gen
folder in the root whereas I was expecting to be generated at package/acme/example/protos/api/v1/gen/hello_pb.ts
.
Edit:
Running another test, if out: ..
when generating, files are created in the parent folder:
../package/acme/example/protos/api/v1/hello_pb.ts
(relative to the root folder)
Edit 2:
When setup out: .
, I'd say it only works because protobuf-es
is creating files using the path ./package/acme/example/protos/api/v1/hello_pb.ts
which coincides with the proto
definition path.
It seems the protobuf-es
is appending the fullname path from here with the out
definition.
Let me know if you need any help to reproduce it please. Thank you!
from protobuf-es.
With this buf.work.yaml
the buf CLI will use packages/acme
as the module root. You can see the files in this module with:
$ cd packages/acme
$ buf ls-files
example/protos/api/v1/hello.proto
So the input file is example/protos/api/v1/hello.proto
, and our plugin will generate a corresponding example/protos/api/v1/hello_pb.ts
.
If you run buf generate
from the repository root, the buf CLI writes the file to example/protos/api/v1/hello_pb.ts
, relative to the repository root and the plugin out
parameter (.
). The plugin is unaware where the source files are on disk, and where the generated files are written to.
from protobuf-es.
Thank you for the explanation @timostamm!
Another related question is that even without buf.work.yaml
, the plugin is generating files relative to the repository root when the plugin out
parameter is .
.
That was the motivation to open the issue in the first place. It'd be nice to be able to generate relative to source files, instead. For example, setting the out
parameter as ./gen
and having the files generated to [root]/package/acme/example/protos/api/v1/gen
folder and not to the [root]/gen
.
from protobuf-es.
I agree that this would be nice - the user experience with buf workspaces is clearly not ideal here - but the plugin really is unaware where the source files are on disk. In the CodeGeneratorRequest it receives, the input file has the path example/protos/api/v1/hello.proto
, and in the CodeGeneratorResponse it produces, the output file has the path example/protos/api/v1/hello_pb.ts
.
The only way to achieve that output files are put to packages/acme
would be to have a plugin option where you can specify output_path_prefix=packages/acme
. And this is something that can already be done with the out
option in buf.gen.yaml, or or the --es_out
flag in protoc.
I recommend a very different approach here: Remove buf.work.yaml and create a proto
directory at the root of your repository:
$ tree proto
proto
├── acme
│ └── example
│ └── api
│ └── v1
│ └── hello.proto
└── buf.yaml
In your buf.gen.yaml, set out: packages/acme/example/src/gen
.
Now you can lint with buf lint proto
and generate with buf generate proto
. Note that this also fixes a lint issue with your setup - we recommend that the protobuf package structure matches the directory structure of the module.
from protobuf-es.
Related Issues (20)
- Runtime error on TextEncoder/TextDecoder HOT 4
- Why is the 'message' type field set as optional? HOT 1
- [feat] Option to generate enum with full prefix HOT 11
- Expose `add` method on registry object HOT 1
- Calling FeatureSetDefaults.fromBinary in a non nodejs runtime fails importing @bufbuild/protobuf HOT 2
- Message name collides with imported message name
- Consider providing a convenient accessor for custom options from Desc* types HOT 2
- Serialize (toJson) Timestamp as date HOT 3
- Non optional timestamp HOT 1
- JsonFormat does not work for proto with optional fields HOT 1
- Register Default Registry HOT 2
- Avoid `instanceof` and remove the "node" export condition
- TypeScript resolves CJS type definitions for ESM code with `NodeNext` module resolution HOT 5
- Comparing messages (Diff) HOT 2
- JSON serialization options HOT 2
- Get T property of FieldInfo HOT 3
- Expose message class's canonical name HOT 4
- Support option retention in @bufbuild/protoplugin HOT 2
- Regression: enum strings are broken in constructor of message types in 1.8.0 HOT 3
- Using message as a value in Map seems to break deserialisation HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from protobuf-es.