Sam Gammon

fwiw that Chrome idea has seen a revival recently, so maybe i will try to go land that PR.

### When using `closure_proto_library`: - This seems to be the new version of the first rule I mentioned. So I tried to depend on it, but, I get the following...

@Yannic, i actually got it to work somehow, i'm still trying to figure out now if i'm using a fork and it's my local state, or if it was fixed...

@Yannic then again, if that one dep supports aliases, and transitive dependencies, that would be fine with us (in terms of `closure_proto_library`). thank you again, this project is awesome and...

@gkdn please, could we merge that PR, pending a better approach? 😁

yes, i think that does help. so it's just that we need to get that PR merged, so we can use that new rule with Soy (just clarifying)?

@Yannic one more question, if you don't mind. our `proto_library` definitions include a `strip_import_prefix` value, which we need to be able to compile them correctly. i would use `closure_js_proto_library` in...

@Yannic actually, using `closure_proto_library` seems to work perfectly, when depending on `proto_library` declarations with `strip_import_prefix`. i'm using it with soy now, building templates (that reference protos) that render correctly, using...

@Yannic, pardon me, i spoke too soon. it was working perfectly because the underlying proto had no imports in it. with a more complex example, i get the following output...

Did some digging and it definitely seems like *rules_closure* is doing what it should. Cross-filed with GCC at google/closure-compiler#3427.