Bazel rules?

[robfig]

After watching
https://www.youtube.com/watch?v=0pgERydGyqo&index=6&list=PLxNYxgaZ8RseY0KmkXQSt0StE71E7yizG

I was wondering if there's any thought / action on implementing bazel rules for plovr? It seems like there would be a big speedup from parallelization and using persistent workers.

[nicks]

I've thought about it. Medium has Bazel rules around Plovr but they are kind of janky and not easily generalizable. They parallelize well, but they also do a lot of do-si-do dancing with plovr JSON templates that's hard to debug. They also don't use persistent workers.

It's not entirely clear to me that you'd want to use plovr build if you're using Bazel. In many cases, people are just using Plovr as a standalone build system, and they'd be better served by using the Closure Bazel rules.

A more compelling use case I thought about was to have a Bazel rule that takes the closure Bazel rules as input, and outputs plovr json. So you would use Bazel for static builds, but Plovr for serving and dynamic rebuilds.

[robfig]

That makes sense. But, we have ~200 plovr configs. It seemed daunting to migrate those to rules_closure compared to having a drop-in plovr target that references them. We do have a custom rule for that that simply runs plovr build, and parallelization does work fine, but it seems like persistent workers would be a significant speedup. We compile in the Plovr servlet for dynamic reloads and only use bazel for production builds -- I would love to use the bazel-built artifact if no changes have been made rather than waiting up to 10s for the plovr compile on the first request, but that seemed tricky.

[nicks]

The problem we ran into when doing the Medium Bazel migration is that Plovr has strong opinions about what the dependency tree looks like, and Bazel also has strong opinions about what the dependency tree looks like. There wasn't a way to have an easy drop-in replacement rule. The solution we ended up with was:

1. The bazel rule lists its inputs and outputs
2. We replaced the Plovr JSON with a "template" json file with input and output as template variables
3. The bazel rule would produce a "real" Plovr JSON file with inputs and outputs that Bazel was ok with.

Your mileage may vary though depending on how your JS is structured. Maybe the answer is that there should be a "plovr bazel" that produces bazel rules based on Plovr JSON

[robfig]

Oh, that's a good point. I solved that by using local = 1 so it has unfettered access to the source tree. 👎 We use auto-inclusion based on goog.require so this would be some work..