interoperate with rules_closure

[yohcop]

It would be nice to have a ts_binary rule that turns ts_libraries into a single .js file.
Unless I miss something and there's already a way to do this?

Maybe with bazelbuild/rules_closure, it would be possible to optimized the output code using closure_js_binary.

[alexeagle]

right, we plan to re-use the closure compiler rules to get a single bundle file

[yohcop]

As a first approximation, would adding a outputFile option in a generated tsconfig file be possible?

[alexeagle]

I think we more commonly want some other bundling tool that knows how to flatten modules, like rollup. @robwormald might look into it next week, angular and ngrx need it soon.

[achew22]

Any luck on this? Feel free to ping me internally if there is any 20% stuff I can do to help 😄

[achew22]

I have a semi-working prototype but it requires google/closure-compiler#2641 to be submitted (at a minimum) due to google/closure-compiler#2637 which lines up with the timeline that Alex was talking about with the es6 module import issue

[unlikely-leo]

Hi there, we're looking into using Bazel for our mixed TS/JS codebase at the moment. Interoperability with the Closure rules to build minified bundles is definitely a key aspect of making that work. It's great to see that this is being worked on!

@achew22 could you clarify what timelines you were referring to in your comment?

[achew22]

@alexeagle looks like the snapshot build of Closure compiler now has the fix for deterministic ordering. Does that mean we can actually do this?

[alexeagle]

Sure, you can pick up from https://github.com/alexeagle/rules_typescript/tree/closure_js_binary?files=1
And just point to the new snapshot build?

[alexeagle]

I think closure compiler is released now, so someone could pick this up.

[codesuki]

@alexeagle is there any update on this or #112 ?
We want to use protobuf + grpc-web but the resulting js file using rollup are nearly 400kb.
I am expecting the size to go down using the closure compiler. Would be comfortable to use it together with rules_typescript.
Thanks for your work!

[alexeagle]

No update, we have been working more on rollup+uglify recently. I hope one of the contributors will have time to push that feature forward. Why does your code optimize poorly with uglify? I suspect that's relatively easy to fix. Let's make a minimal example of using protobufs and grpc for others to follow, and have the CI enforce that the result is optimizable?

…

On Sun, Mar 4, 2018 at 11:43 PM Neri Marschik ***@***.***> wrote: @alexeagle <https://github.com/alexeagle> is there any update on this or #112 <#112> ? We want to use protobuf + grpc-web but the resulting js file using rollup are nearly 400kb. I am expecting the size to go down using the closure compiler. Would be comfortable to use it together with rules_typescript. Thanks for your work! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC5I72OTJFf4O9S-pIE8hualSVGoqHuks5tbOy6gaJpZM4N0M0k> .

[codesuki]

I am not sure yet. Still in the middle of investigating. My front end dev told me using grpc is unacceptable because the bundle size is around 400kb. We are using https://github.com/improbable-eng/grpc-web/ which has a dependency on google protobufjs, that's all I think.
I ran the closure compiler with extended flags on the rollup output and the file became 200kb, but I guess it's broken because I didn't have time to delve deep and set the right exports.

Anyway, if I may ask, are you moving away from closure internally? In another PR / Issue you mentioned you don't want to support any closure stuff because it's not much used.
I thought dead code elimination seemed like a nice feature, but I am not up to date with front end dev anymore.

Are you guys using grpc or protobuf from browsers? If so do you have much smaller file sizes?
That info would help me a lot 😓

I will try to make an example using rules_typescript with grpc-web and rollup.

edit:
If the readme of protobuf js is correct

The library is currently compatible with:
CommonJS-style imports (eg. var protos = require('my-protos');)
Closure-style imports (eg. goog.require('my.package.MyProto');)

That would mean that tree shaking is not supported, but maybe I am wrong.

[pcj]

For comparison, I'm using an internal grpc-web front-end implementation that's all closure. The whole app (with closure templates and all) minifies down to 154kb with advanced compile/no debug symbols. IIRC the grpc part alone was about 80kb, so it is possible to have reasonable bundle sizes with gRPC. Have not tried with rollup but seems like it should be possible to get close to that.

[codesuki]

@pcj thanks for providing that reference data! Very helpful 👍
I got it down to 80kb with gzipping it, but I am not sure that's a normal thing to do.

After doing some more investigation I found that the main culprits are the generated proto files.

app - 254.43 KB (47.08%)
	proto/event/client/event_pb.js - 39.53 KB (15.54%)
	proto/feature/user_pb.js - 39.25 KB (15.43%)
	proto/gateway/service_pb.js - 31.88 KB (12.53%)
	proto/feature/feature_pb.js - 26.21 KB (10.30%)
	proto/feature/strategy_pb.js - 24.77 KB (9.74%)
	proto/feature/evaluation_pb.js - 17.57 KB (6.91%)
	proto/feature/rule_pb.js - 8.33 KB (3.27%)
	proto/feature/clause_pb.js - 7.98 KB (3.14%)
	proto/feature/variation_pb.js - 7.35 KB (2.89%)
	proto/feature/target_pb.js - 6.39 KB (2.51%)

The next big thing is google-protobuf itself.

google-protobuf - 166.34 KB (30.78%)
buffer-es6 - 53.75 KB (9.95%)
grpc-web-client - 42.19 KB (7.81%)

Sorry this went totally off-topic. I know this is not the protobuf repo, but do you have any guidelines or best practices to keep the generated proto files small?

[schmitch]

@alexeagle is there any progress on this?

[alexeagle]

Nope, no progress.

…

On Thu, Mar 22, 2018 at 9:44 AM Schmitt Christian ***@***.***> wrote: @alexeagle <https://github.com/alexeagle> is there any progress on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC5Iz0rPHkcT71S7Kp3lcCkICe8HhXlks5tg9T3gaJpZM4N0M0k> .

[ribrdb]

@schmitch If you want to compile a ts library down to a .js file using the closure compiler, you can try
https://github.com/ribrdb/rules_closure/tree/ts
With that you can add a ts_library in the deps of any closure_js_binary()
You may also need to use https://github.com/ribrdb/rules_typescript/tree/closure to get the typescript to run through tsickle before compiling it with closure.
I thought I sent a pull request for that, but it looks like I never did.

[alexeagle]

Hmm, the `.closure.js` outputs from the standard upstream ts_library rule should already be run through tsickle. I'm curious what was missing there

…

On Thu, Mar 22, 2018 at 11:30 AM Ryan Brown ***@***.***> wrote: @schmitch <https://github.com/schmitch> If you want to compile a ts library down to a .js file using the closure compiler, you can try https://github.com/ribrdb/rules_closure/tree/ts With that you can add a ts_library in the deps of any closure_js_binary() You may also need to use https://github.com/ribrdb/rules_typescript/tree/closure to get the typescript to run through tsickle before compiling it with closure. I thought I sent a pull request for that, but it looks like I never did. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC5I4ZkauPk2f19ifZeTId2XXXQ8Hu8ks5tg-3HgaJpZM4N0M0k> .

[kalbasit]

@alexeagle is there any examples of using closure_js_binary with a ts_library? Do we need #174 for this to work? I can't seem to get it to work.

EDIT: I got it to work, see #174

[alexeagle]

#344 has more recent discussion so let's continue there