Hacker News new | ask | show | jobs
by fenos 2736 days ago
Fantastic! I've never had a chance on launching the app on windows, I'm glad it worked!

I think you are running the dev mode, that's why the Chrome dev tools appeared :)

The import paths feature will be released soon so stay tuned! In the meantime, you can temporarily place the imported protos close to the one you want to use

Ty
1 comments
quietbritishjim 2736 days ago
Sorry I didn't call this out more clearly, but I think the server-hot vs hot-server thing is a typo in the readme that's wrong on any platform.

Looking forward to include path support. I tried flattening my protos into one directory, updated all their `import` directives and gave it a go, and it works great, thanks! Both client and server running on Windows. My protos use a well known type (google.protobuf.Duration) and I was particularly impressed that it worked without me having to copy in the proto file for that.

I'm sure you already know this, but just in case: Include paths don't just help with proto files scattered across different directories, they also allow part of the path to be part of the canonical name of the proto. [1, 2] For example, if you have these files:

    /
        src/
            xyz/
                foo.proto   # Contains: import "xyz/bar.proto"
                bar.proto
Then you need -I/src (or similar) because if you run protoc from within /src/xyz/ without -I then it's like you specified -I/src/xyz, and then foo.proto can't find bar.proto (because it looks for /src/xyz/xyz/bar.proto). Using relative paths like this is useful because you can have proto files with the same file name (like "config.proto") so long as their full canonical name is different, and because generated files are output into corresponding subdirectories (which is especially useful in Python where the subdirectory indicates the package name).

[1] https://stackoverflow.com/questions/18735609/the-path-in-pro...

[2] https://github.com/protocolbuffers/protobuf/issues/723#issue...

link